Translate

terça-feira, 13 de dezembro de 2016

Enfim, Knoppix 7.7.1 em Live USB (Pendrive) com "persistência"

Tela inicial do Knoppix já com as configurações da sessão anterior, carregado a partir do Pendrive
Knoppix 7.7.1 em Live USB (Pendrive), com “persistência” das configurações anteriores

Finalmente, uma instalação do Knoppix 7.7.1 em Pendrive (16 GB), — funcional, — com “Persistência”.

Ao inicializar o computador, o “Live” Knoppix carrega com as configurações feitas nas sessões anteriores, — complementadas pela opção “Restore saved session” do KDE:

  • Wallpaper (em “/home/Pictures”)
  • gKrellm com informações adicionais, na posição escolhida
  • Dolphin personalizado, — e com várias abas, abertas em pastas predefinidas
  • Konsole em tamanho e posição “discretos”, — com memória dos comandos “gnome-screenshot”, inclusive padrão de nome e pasta de destino
  • Partições “E:\” e “F:\” montadas automaticamente ao iniciar
  • Teclado PT-BR, com tecla de acesso ao 3º nível, e NumLock ativado
  • Tema “Maia Transparent”
  • Decoração de janelas ”Transparent Oxygen”
  • Busca de arquivos desativada
  • KDE Wallet desativado
  • Compositor OpenGL 2.0, — falta testar XRender
  • Sem animação de Minimize / Maximize windows
  • Gwenview configurado para fechar com “Esc”
  • etc.

Análise combinatória


Digo “uma” instalação funcional, — porque já foram experimentadas várias alternativas, — e ainda há mais algumas que gostaria de tentar.

Existem várias opções, ao longo do processo, — e o número de combinações possíveis, entre tantas opções, é enorme:

  1. Instalar a partir de uma sessão Live DVD de 32bit ou de 64bit
  2. Instalar a partir de uma sessão DVD com LXDE (default) ou KDE
  3. Instalar pelo “cheat code” inicial “knoppix tohd”, — ou mais tarde, pelo Menu
  4. Pelo Menu, — “HD install”, — ou “install to flash disk”
  5. Dentro da instalação pelo Menu, — opção “r” (removable only) ou “h” (also HDD)
  6. “Persistência” via “Overlay file”, — ou via “Overlay partition”
  7. Várias outras opções “poor man’s install”
  8. Várias opções de instalação por mera “cópia”
  9. Gnome, — em vez de LXDE ou KDE
  10. Instalação sem carregar nenhum “ambiente gráfico”
  11. Instalar a partir do DVD “real”, — cuja gravação pelo K3b parece sempre apresentar “erro” no final, — ou do “pseudo-DVD” gerado pelo UNetBootin, que altera a ISO, ao adaptá-la para Pendrive, e não apresenta “erro” no final
  12. Instalar a partir de um DVD encomendado pronto na Alemanha
  13. etc.

Considerando apenas as primeiras 6 opções, — binárias, — o número de combinações possíveis é assustador.

Portanto, era conveniente limitar as hipóteses sobre possíveis causas de insucesso, — e portanto, sobre possíveis caminhos para se alcançar melhor resultado, — começando pelas alternativas menos onerosas e menos demoradas (encomendar na Alemanha, esperar, Alfândega etc.).

Opções utilizadas


O caminho seguido nesta experiência foi:

  1. Gerar o DVD pelo K3b, — a partir da (mesma) imagem ISO (4,3 GB) usada antes, — e ignorar o “erro” no final
  2. Testar o Knoppix Live DVD pelo comando “knoppix testcd tz=America/Sao_Paulo desktop=kde”, — que examina a mídia e, se tudo estiver Ok, carrega em seguida, já com o fuso horário de Brasília e ambiente KDE
  3. Fazer o mínimo de configurações, para não perder tempo com (mais) uma tentativa que talvez não desse certo, — como já não deram certo várias outras, antes
  4. Menu → Knoppix → Install to flash disk
  5. Opção “h”, — “Allow installation also on fixed disks”
  6. Opção “i”, — “Installation on FAT32 with (optional) overlay file < 4 GB”, — sem encriptação do arquivo de “persistência”

Partir de um DVD “de verdade”, — embora com “erro”, segundo o K3b, — era uma alternativa ainda não experimentada, — e o fato de (finalmente) obter bons resultados merece ser registrado.

Dentro dessas opções, preferia ter uma “partição de Overlay”, — não um “arquivo de Overlay”, com extensão “.img”, — embora, em tese, este “arquivo-imagem” possa ser montado e aberto em outros Linux*.

(*) Ainda não foi obtida montagem e abertura pelo Dolphin ou Konqueror, a partir de outros Linux. A ver: — se alterações feitas a partir de outros Linux irão causar rejeição, depois, pelo Knoppix, — ou qualquer outro efeito colateral.

No entanto, “overlay file” era uma opção ainda não experimentada, — e como deu bons resultados, isso também merece registro.

Também faltava experimentar a opção “h”, — aplicável “também para disco fixo”, embora presente na instalação pelo “Menu → Knoppix → Install to flash disk”, — e como o resultado geral foi bom, isso é outra coisa que merece registro.

Enfim, vale registrar que foram usados os “cheat codes” — “knoppix testcd” etc., — ou seja, rodando em 32bit, — e não “knoppix64 testcd” etc. — E como deu bons resultados para uso posterior em 64bit, isso parece indicar que a opção usada, se não fez nenhum bem em especial, pelo menos parece não ter prejudicado.

Resultados


Existem algumas demoras, às vezes, quando se iniciam novas tarefas, — talvez, por insuficiência de Memória RAM, ou de CPU, — já que o Knoppix trabalha com descompressão “on-the-fly” de 11 GB de pacotes comprimidos em 4,3 GiB na ISO / DVD, — além de combinar dados de pastas de sistema no arquivo KNOPPIX (inalterável) com dados das “mesmas” pastas, guardados no “arquivo overlay”.

No entanto, — apesar dessa sobrecarga para a CPU e a Memória RAM, — o Chromium enfrenta bravamente os obstáculos que o Facebook opõe para desestimular a visitação e viralização de “páginas” (mesmo as que pagam), —  façanha que (ainda) não foi conseguida no Kubuntu 17.04, nem no Debian testing (instalados em HDD / SSD, e sempre atualizados), — o que coloca este Live USB Knoppix 7.7.1 (Pendrive de 16 GB) entre as melhores alternativas para trabalho regular prolongado.

E, — uma vez que mantém as configurações e os históricos do Konsole, do Dolphin, do Chromium etc., — está pronto para o trabalho, 2 minutos após ligar o computador.

Download e gravação


A imagem ISO ainda era a mesma baixada em 4 Nov. 2016, — e agora foram baixados também os arquivos “md5”, para conferir (apenas visualmente) a verificação feita pelo K3b.

1) A primeira tentativa de gravação pelo K3b foi feita no Kubuntu 17.04 Zesty Zapus (development branch), com a opção “Verificar os dados gravados”, e “velocidade automática”. — O K3b adotou “16,4x” (velocidade indicada na mídia), embora registrasse, de fato, 6,70x, 8,60x, 11,80x, 13,70x, 14,50x, 14,00x, — e a saída de energia de 12V manteve-se em 12,25V, com momentos de 12,30V no início e no final.

O andamento da tarefa estacionou por longo tempo em “98%” da gravação, — e acusou “Erro fatal durante a gravação de: Argumento inválido”, aos 6 min 54 seg do primeiro tempo, — coisa que, para um leigo em “tecnologia”, agora parece relacionado unicamente com o “fechamento” do DVD já gravado.

Infelizmente, o DVD foi jogado no lixo, e agora já não convém colocá-lo na bandeja, pela simples curiosidade de testá-lo, — embora a tentação seja enorme, — pois, agora, tenho certeza de que provavelmente funcionaria com perfeição.

2) A segunda tentativa de gravação pelo K3b foi feita no Linux Mint 18 KDE (ex-beta), — novamente, com a opção “Verificar os dados gravados”, — porém limitando a velocidade a “4x”.

Na prática, a velocidade variou entre 3,50x e 4,10x, — a saída de energia de 12V permaneceu em 12,25V, — até 99%, aos 14 min 23 seg do primeiro tempo, onde estacionou por um minuto, e acusou “Erro fatal durante a gravação de: Erro de entrada / saída” aos 15 min 41 seg.

Infelizmente, o segundo DVD também foi para o lixo, e agora não vale a pena arriscar colocá-lo na bandeja, só por uma curiosidade.

3) A terceira tentativa foi feita no Kubuntu 16.04 LTS, — porém sem verificar os dados gravados, — e novamente com velocidade limitada a “4x”. Por mera “superstição”, não foram feitas capturas de tela (só 1 foto).

Nova parada aos 99%, e por fim, a mesma mensagem de “Erro fatal durante a gravação de: Erro de entrada / saída”, aos 15 min 40 seg do primeiro tempo.

Sem encontrar qualquer dica sobre modos de gravação, — K3b, “dd”, “cp” etc., — no site e no forum do Knoppix (exceto um conselho de usar “4x”), o terceiro DVD foi simplesmente deixado na bandeja aberta (para esfriar a cabeça), e o computador reiniciado após alguns minutos.

Este terceiro DVD funcionou com absoluta perfeição, — até onde alcança a percepção de um simples leigo nessas coisas de “tecnologia”. — Deu partida no sistema, se auto-testou, carregou o Knoppix 7.7.1 KDE, realizou a instalação no Pendrive (16 GB), — e o “Live Pendrive” está funcionando até hoje.

••• Epa


Após uma curta sessão LXDE, — onde não foi feita nenhuma configuração, — algumas coisas deixaram de funcionar nas sessões KDE.

••• Install to flash disk + Overlay partition


Várias experiências de instalação foram realizadas a partir do primeiro “pseudo-DVD”, — Pendrive de 8 GB gerado pelo UNetBootin a partir da ISO-DVD, por ele modificada para adaptação à mídia USB.

Duas experiências, — nos dias 9 e 11 Novo, documentadas aqui, — utilizaram a opção “Menu → Knoppix → Install to flash disk”, opção “r” (removable only), tendo como destino um Pendrive de 32 GB, e opção de “Overlay partition” ocupando todo o espaço restante na mídia.

Na primeira experiência, tinham sido instalados “Flashplugin” e “ttf-mscorefonts”, antes de iniciar a instalação do Knoppix no Pendrive de 32 GB. — Da segunda experiência em diante, esses 2 componentes nunca mais foram instalados, — nem antes, nem depois.

Nas horas e dias seguintes, o Knoppix instalado no Pendrive de 32 GB mostrou-se muito lento, — motivo pelo qual, aquele relato teve de ser produzido no Knoppix “Live pseudo-DVD” gerado pelo UNetBootin (Pendrive 8 GB).

8 Nov., 1:45 - Pseudo-DVD (Pen 8 GB) - Sessão LXDE. - 3:33 - Sessão KDE. - 4:02 - Off. - Pela manhã, histórico estranho no Chromium do Kubuntu.

17:46 - Pseudo-DVD (Pen 8 GB) - 1:37 a 2:11 - Instalação no Pen 32 GB.

9 Nov., 2:19 - Pendrive 32 GB - Não trouxe nenhuma configuração da sessão Live de instalação. - 3:37 - Off.

9 Nov., 10:31 - Pendrive 32 GB - Com persistência da sessão anterior (Wallpaper, Dolphin, Konsole), porém tudo fora de lugar [Só tempos depois, recorri às configurações do KWin para que o Dolphin lembrasse sua posição]. Registros de demoras. - 17:01 - Shutdown.

10 Nov. - 19:22 - Pseudo-DVD (Pen 8 GB) - Constatada a agilidade do “pseudo-DVD”, em comparação com o “instalado”. - [A sessão não foi encerrada].

11 Nov., 7:23 - Pseudo-DVD (Pen 8 GB) - [Ainda a sessão iniciada na véspera] - 11:26 - Shutdown.

12:27 - Pendrive 32 GB - Lentidão, demoras etc. “Inútil como Live SO”. 13:40 - Shutdown.

17:55 - Pseudo-DVD (Pen 8 GB) - Configurando apenas o essencial. - 19:38 a 20:23 - Nova instalação no Pendrive de 32 GB. - 21:57 - Shutdown.

22:06 - Pendrive 32 GB - Novamente, não trouxe configurações da sessão de instalação. - 22:45 - Restart. Persistiram (parcialmente) configurações feitas após “instalado”. Registro das demoras. 23:51 - Shutdown.

12 Nov. - 7:48 - Pendrive 32 GB - Persistiram as configurações da véspera (Na verdade, vários detalhes ainda dependiam de ajustes adicionais no KDE e do KWin, para de fato se manterem de uma sessão à outra). Registros das demoras. - 10:06 - Shutdown.

10:14 - Pseudo-DVD (Pen 8 GB) - Configurações (roteiro básico). Trabalho regular e produtivo. Produção do relato. 23:19 - Shutdown.

13 Nov., 9:02 - Pendrive 32 GB - Mesmas demoras, até certo ponto suportáveis. O bicho realmente começa a pegar após abrir o Chromium. Aliás, parece que o Knoppix “atrai” problemas de conexão web, quando comparado com os outros 5 Linux (instalados em HDD / SSD). Mas os registros (salvo subjetivismos ao anotar) confirmam que os problemas, dificuldades e demoras tendem a se alastrar e “persistir” no Knoppix “instalado com persistência” (Pendrive 32 GB), ao passo que no Knoppix “Live pseudo-DVD” os problemas tendem a se resolver por si sós, em pouco tempo. - 9:59 - Shutdown.

10:07 - Pseudo-DVD (Pen 8 GB) - Configurações (roteiro básico). Trabalho regular e produtivo. Produção do relato. - 21:19 - Shutdown.

14 Nov., 5:47 - Pseudo-DVD (Pen 8 GB) - Configurações (roteiro básico). Trabalho regular e produtivo. Produção do relato. - 20:18 - Shutdown.

Até aí, portanto, o quadro era:

  • Um Knoppix bastante funcional e produtivo, no Pendrive de 8 GB, mas sem “persistência”, — configurar outra vez, a cada nova sessão; e

  • Um Knoppix no Pendrive de 32 GB, com “persistência” das configurações, — porém impraticável para o trabalho.

••• knoppix tohd=/dev/sd[X][N] mkimage


Depois das 2 tentativas “Instal to flash disk”, foi experimentada uma das opções genericamente chamadas “poor man’s install”, — carregar com o comando “knoppix tohd=/dev/sd[X][N] mkimage”.

Após a instalação, é necessário continuar dando boot pelo Pendrive (ou DVD), — e comandar “knoppix fromhd=/dev/sd[X][N]”, — procedimento que evidencia a “pobreza” dessa alternativa.

De início, o Knoppix foi carregado a partir do Pendrive 32 GB, — com o comando “knoppix tohd=/dev/sdd3”, — esquecendo o “mkimage”.

Para isso, o drive externo SSD foi plugado após o Pendrive, — logo que o Boot chegou ao prompt do Knoppix, — caso contrário, a partição “Linux6” poderia vir a ser “sdc3”. — [Isso talvez possa ser organizado de modo mais racional, no BIOS Setup].

Além disso, o arquivo “/boot/syslinux/syslinux.cfg” do Pendrive 32 GB foi editado para incluir os “cheat codes” de fuso horário e ambiente gráfico, — “tz=America/Sao_Paulo desktop=kde”, — coisa que não produziu o efeito esperado [Exame dos prints sugere que foi editado por um zumbi desacordado].

Ao final da instalação, rapidíssima, — 5 minutos, em modo texto, sem pergunta alguma, — foi carregado o ambiente LXDE.

Teoricamente, o esquecimento da última parte do código, — “makimage”, — poderia ser remediado em seguida, acrescentando este “cheat code” ao carregar pela primeira vez.

Foram feitas 2 tentativas, sem êxito, — talvez, por não serem feitas logo no primeiro carregamento após a instalação.

Em retrospecto, um dia iniciado às 5:47 não deveria se prolongar tanto, — evidenciam-se várias falhas de atenção, — e outras parecem bastante prováveis.

14 Nov., 20:48 - Pendrive 32 GB - “knoppix tohd=/dev/sdd3”.

20:54 - Instalação concluída, — carregou LXDE. — 21:23 - Shutdown.

21:28 - Pendrive 32 GB - “knoppix64 fromhd=/dev/sdd3 tz=America/Sao_Paulo desktop=kde”. - Enfrentou com galhardia os obstáculos do Facebook. - 22:15 - Shutdown.

22:18 - Pendrive 32 GB - Erro de comando, — “fromhd=/sdd3”, — sem “/dev”.

22:24 - Pendrive 32 GB - “knoppix64 fromhd=/dev/sdd3 mkimage”. - Carregou LXDE. - 22:26 - Shutdown.

22:28 - Pendrive 32 GB - “knoppix64 fromhd=/dev/sdd3” (+tz, kde). - Feitas algumas configurações, para conferir a “persistência”. - 22:36 - Shutdown.

22:40 - Pendrive 32GB - “knoppix64 fromhd=/dev/sdd3” (+tz, kde). - Sem “persistência” das configurações feitas minutos antes. Pasta “/home/Pictures” sem o wallpaper colocado lá.

15 Nov. - A partição foi apagada, e foram feitas novas tentativas de instalação “tohd / fromhd”, com mais atenção, porém provavelmente também com erros. Sem êxito.

__________
• Publicado inicialmente em 13 Dez. 2016, às 10:43, e desenvolvido até o dia 14, no próprio Knoppix 7.7.1 em “Live USB”, a partir da instalação no Pendrive de 16 GB.
••• 

— … ≠ • ≠ … —

Knoppix



Ferramentas &tc.


Postado por Mboaba às terça-feira, dezembro 13, 2016 0 comentários
Marcadores: , , , , ,

sábado, 3 de dezembro de 2016

Ensaio de avaliação com luckyBackup e Unison

Monitoramento de tensão e temperatura no backup inicial com Unison

O “ensaio” teve, como ponto de partida, o acréscimo de um drive externo SSD de 1 TB, — possibilitando um segundo backup, mais completo, — e como alvo, um futuro HDD interno de 1 TB, que vai alterar toda organização de arquivos, pastas e backups.

Trata-se de uma avaliação real, particular, específica: — (1) usuário “leigo”; — (2) envolvimento de todo o sistema (não uma “VM”); — (3) reflexos em todas as rotinas de trabalho; — e não uma “avaliação técnica”.

O objetivo é estudar alternativas e rotinas de backup, nesta máquina, para quando instalar o futuro HDD.

Sequência da reorganização



Estrutura de partições


Particionamento dos atuais HDDs de 320 GB: documentos no primeiro, backup no segundo

Há vários anos, todos os arquivos de trabalho ficam em partições Fat32 herdadas do antigo Windows XP, — aqui referidas como “E\:” e “F\:”, — de 70 GiB e 180 GiB, no primeiro HDD interno.

Também há vários anos, o backup é feito nas partições “Home2” (73,5 GiB) e Home1 (176 GiB), — pertencentes ao “Linux2” e ao “Linux1”, — no segundo HDD interno.

O drive externo SSD de 1 TB, — usado, e já um tanto antigo (2011), — não oferece tranquilidade para substituir (eliminar) os backups em HDD, por se tratar de tecnologia com menor vida útil, em número de gravações e leituras.

No entanto, permite acrescentar um segundo backup,— segurança adicional, — e isso abriu oportunidade para ensaiar novos métodos de backup, além de algumas correções nas rotinas seguidas até agora.

O objetivo “final”, portanto, era “ensaiar” novos procedimentos, — para quando for instalado um novo HDD interno de 1 TB, — que, com certeza, vai “revolucionar” a atual estrutura de pastas.

Como ficará claro, estruturas de pastas, nomes, rotinas etc. não costumam ser alterados com frequência, — pequenos “incômodos” ficam em observação por longos períodos, dando tempo ao planejamento de correções, e mais algum aprendizado.

A ideia é mexer o mínimo possível, ir devagar, e documentar tudo, — pois sempre haverá tempo para aprender, e será menos difícil corrigir as burradas.

Backup parcial com luckyBackup


Nomes desencontrados nas pastas de origem e destino dos backups

A rotina de backup seguida até aqui, — usando o luckyBackup, — abrangia só algumas das pastas existentes nas partições de trabalho “F:\” e “E:\”, — as pastas onde se concentram os arquivos de trabalho atualmente em uso.

Para receber os backups, tinha criado, manualmente, igual número de pastas de destino em “/Home1/flavio/Backup/”, — com nomes arbitrários, diferentes das pastas de origem.

Por inexperiência, as pastas de origem eram “clonadas”, criando uma sub-pasta, — com o nome correto, — dentro de cada uma dessas pastas.

Isso apenas complicava a navegação pelos backups, — abrir uma pasta, depois a sub-pasta, — sem nenhuma utilidade prática.

Opção de criar (clonar) a pasta de origem dentro da pasta de destino

Uma alternativa que se apresentou, logo no início deste “ensaio”, era marcar a opção “Do NOT create extra directory”, — e neste caso, apenas o conteúdo da pasta de origem seria duplicado dentro de cada pasta de destino.

A princípio, o “ensaio” foi direcionado neste sentido, — e após fazer a cópia do conteúdo, o próprio luckyBackup se encarregava de eliminar a “pasta extra” (clone), — o que foi bastante conveniente, pois o espaço livre na “Home1” já andava perto do limite.

Depois, relendo o aviso com calma, — ao marcar a mesma opção nas demais “tarefas”, — a palavra “clone” mostrou seu valor.

Inúmeras configurações, links, comandos, rotinas etc. estão associados aos nomes dessas pastas, nas partições “F:\” e “E:\”, — e é esse estado de coisas que será necessário restaurar, en cas de malheur, — mas isto seria bem mais difícil, se persistisse na burrice de colocar os backups em pastas com outros nomes, arbitrários.

Simplificando o luckyBackup


Novo comando do luckyBackup: — clonar as pastas de origem dentro de uma grande pasta de destino

Portanto, as “tarefas” do luckyBackup foram reorientadas para “/Home1/flavio/Backup/”, — e restabelecida a permissão para criar pasta “extra”, — vale dizer, “clonar” as próprias pastas de origem, dentro de uma grande pasta de destino.

Exceção foi feita aos 4 sites HTML, — agrupados em “/Home1/flavio/Backup/sites/”, — pois envolvem dezenas de milhares de links internos, e devem ser editados unicamente no Dreamweaver, para manter a integridade do conjunto (motivo de estarem em “E:\”, não em “F:\”).

Desastre “light”


Partição “Home1” lotada, — por não ter apagado (manualmente) as pastas antigas

Restou o problema de eliminar as antigas pastas com nomes arbitrários, — cada uma, contendo o clone de uma única pasta, — pois a “lógica” da nova rotina não as eliminaria automaticamente.

Isso ficou óbvio, quando a “Home1” rapidamente se entupiu.

Acontece que, por inexperiência, — e talvez devido a dificuldades para gravar em partições que não pertenciam ao Kubuntu, — há vários anos o luckyBackup vem sendo usado sempre em modo Root.

Menu → Utilitários → luckyBackup
Menu → Sistema → luckyBackup (super usuário)

Este “ensaio”, — e o exame para produzir o registro, — mostrou algumas consequências dessa opção, da qual já nem tinha consciência, após tanto tempo.

Entupida a partição “Home1”, o Dolphin não tinha permissão para eliminar as pastas antigas, — cada uma, contendo um arquivo oculto do luckyBackup, — ou seja, “propriedade do Root”.

Aliás, nem a Lixeira podia ser esvaziada, por conter 2 pastas com arquivos ocultos, — que não sei como foram parar lá, pois o luckyBackup costuma excluir por completo.

Dolphin do Kubuntu 16.04 LTS, — sem “Abrir como Root” no Menu de contexto (right-click)

O mais simples seria abrir a Home1 “como Root”, e deletar todas as pastas antigas, de uma vez só, — mas no Kubuntu 16.04 LTS, por algum motivo, o Menu de contexto (right-click) não oferece esta opção.

Comandos e mais comandos, — para não conseguir deletar uma pasta

O comando “sudo rmdir” também não foi capaz de excluir uma única pasta, — seria preciso entrar nela, dar outro comando para esvaziá-la, — ou abrir um parêntesis nesse aprendizado, para iniciar outro aprendizado… com o risco de ter de abrir um terceiro sub-parêntesis, para outro sub-aprendizado, — situação um tanto quanto kafkiana, no meio de um mini-desastre, no meio de um “ensaio” já meio enrolado.

Aliás, aprendizado de emergência para “deletar em massa”, — em momento de pânico, — não é recomendável.

Dolphin no Linux Mint 18 KDE, — “Abrir como Root” no Menu de contexto (right-click)

Nessas horas, é muito prático passar para o Linux Mint, — e resolver tudo numa tacada só, em cerca de 2 minutos, — usando o Menu de contexto para abrir a “Home1” (do Kutuntu) como Root.

Faltava habilitar a opção “Excluir” (sem passar pela Lixeira) no Menu de contexto do Dolphin do Mint

Faltava habilitar a opção de “Excluir”, — sem passar pela Lixeira, — no Menu de contexto do Dolphin, mas isso não tomou nem 1 minuto.

Dolphin aberto “como Root”, — “Excluir” 21 pastas (cheias) de uma só vez

Com isso, bastou selecionar todas as pastas começadas por “b_”, — e mandar Excluir, — para a “Home1” ficar com apenas 44,8 GiB ocupados e 122,2 GiB de espaço livre.

Agora, — ao fazer o levantamento do “ensaio” e produzir um registro detalhado, — é uma boa hora para aprender mais, sem risco de cometer burradas.

O comando “rmdir” serve para apagar diretórios vazios. — Para diretórios cheios, poderia usar “rm b_Byteria/ -R”, por exemplo, que apagaria o conteúdo (recursivamente), sem fazer perguntas, — mas também, sem direito a arrependimento.

No Kubuntu, as configurações do Dolphin e do Konqueror, — seção “Serviços”, — não oferecem a opção “Abrir como Root”, para ser habilitada.

No entanto, digitando “root” no Menu do Kubuntu, teria encontrado “Menu → Sistema → Krusader (modo Root)”, — que resolveria o problema num piscar de olhos.

Reorganizando pastas de origem


Diferenças de ordenamento alfanumérico entre o Dolphin e o Nemo

O “ensaio” também foi aproveitado para fazer algumas mudanças de nome nas pastas de origem:

    _Novas-no-Site   → 000_Novas-no-Site
   _Scanner_entrada → 000_Scanner_entrada
000_print-screen    → 000_print-screen

O motivo, — em observação há alguns anos, — é que aplicativos diferentes usam critérios diferentes de classificação alfanumérica, em seus diálogos de navegação para localizar arquivos, — de acordo com sua origem (Gnome, KDE) e/ou as “bibliotecas” que utilizam.

Nos diálogos de alguns aplicativos, arquivos com nomes iniciados por sublinhado (“_”) são colocados no topo, — tal como no Windows XP, — enquanto, em outros, a classificação ignora o sublinhado e considera apenas as letras ou números que vêm depois dele.

Adaptação dos comandos luckyBackup aos novos nomes de pastas de origem

Portanto, o único modo de garantir que uma pasta muito utilizada apareça sempre no topo, é usar nomes começando por “000”.

Felizmente, a pasta “000_print-screen” é recente, e já incorporava essa manha, — pois qualquer alteração em seu nome implicaria alterar as configurações do Kubuntu LTS, Linux Mint, KDE Neon, Debian, e Kubuntu 17.04 Zesty Zapus.

Obs.: - Diferentes quantidades de zero, — em especial, quando seguidos de outro(s) número(s), — também podem dar margem a classificações diferentes, em diferentes aplicativos (Verificar pastas contendo arquivos com nomes apenas numéricos, como páginas de livros).

Re-clonagem com luckyBackup


Início da re-clonagem das pastas selecionadas, pelo luckyBackup, com monitoramento de energia

Deletadas as pastas do antigo backup, a “Home1” ficou com 44,8 GiB ocupados e 122,2 GiB de espaço livre.

A soma dá apenas 167,0 GiB, — e de fato, esse parece ser o limite “real”, embora o tamanho nominal seja de 176 GiB, — pois meia hora antes (22:56), quando a ocupação da “Home1” chegou a 167 GiB, o sistema emitiu alerta de 0% de espaço livre.

Essa ocupação de 44,8 GiB, após a “limpeza”, inclui 2 pastas que já tinham sido clonadas antes, — total ou parcialmente, — pelas novas regras de backup, e que por isso não foram apagadas. Também inclui 2 pastas que ainda estavam na Lixeira, que só foi esvaziada mais tarde, com nova ajuda do Linux Mint.

Relatório do luckyBackup, ao final da re-clonagem

O luckyBackup foi disparado, então, às 23:31, — com monitoramento de temperatura e das saídas da fonte de energia, — e concluiu a re-clonagem em 52 min 51 seg, por volta da 00:24, relatando a transferência de 104,65 GB.

O Conky indicava ocupação de 143 GiB na “Home1”, — e o Dolphin indicava 24,5 GiB livres, — o que soma 167,5 GiB.

A temperatura do primeiro núcleo (Core0) ficou abaixo de 61ºC, nos últimos 10 minutos da cópia, — mas os níveis de energia não foram documentados.

Backup total com Unison


Ao abrir o Unison, é necessário escolher um “Perfil”, — criar um, se não existe, — ou sair

O segundo backup, — abrangendo todo o conteúdo das partições “E:\” e “F:\” para uma pasta na partição “Terabyte” (exFAT, 795 GiB), — foi “ensaiado” no Unison, por vários motivos:

  • Explorar uma alternativa, que já não lembrava como funciona

  • Evitar eventual conflito ou sobreposição de arquivos ocultos (logs) do luckyBackup, por desconhecer praticamente tudo sobre as entranhas de seu funcionamento

Se até então não lembrava como funciona o Unison, depois de 6 dias continuo não lembrando absolutamente nada, — ao ponto de duvidar que o tivesse usado regulamente, durante 2 anos, de Set. 2012 a Ago. 2014, com um intervalo entre Fev. e Ago. 2013, — até encontrar os logs da época, com todos os detalhes (ver “História antiga”, no final).

Crash em todas as tentativas de criar um novo “perfil” no Unison

A primeira coisa que o Unison exige, é que você escolha um “Perfil”, — e felizmente, no Kubuntu 16.04 LTS, já veio com um perfil “Default” (vazio).

Isso porque, no Kubuntu 16.04 LTS, ainda não foi possível criar novo perfil, — o assistente “Profile creation” fecha abruptamente (levando junto o Unison), tão logo escolho a pasta ou unidade de origem, ou de destino (o que tentar primeiro), — e continua impossível, após 6 dias.

Adicionando uma “Preferência” ao perfil “Default” do Unison

A única solução viável foi editar o perfil “Default”, adicionando as 3 únicas coisas que pareciam fazer algum sentido, para um pobre leigo ignorante:

  • Preferência → Fat → Boolean: True
  • Origem → “/media/flavio/F” — (partição “F:\”)
  • Destino → “/media/flavio/Terabyte/Backup/part_F”

O que entender por “no archive files were found”, — em uma partição cheia até as bordas?

Um aviso aterrorizante diz um monte de coisas ininteligíveis, — tipo, “no archive files were found”, — exceto a parte onde aventa a hipótese de a “culpa” (sei lá do quê) ser do fato de se tratar da primeira sincronização (ufa!).

Pode-se imaginar que esteja reclamando (apenas) da pasta de destino, que de fato ainda estava vazia, — ou talvez, da inexistência de arquivos de log (no plural?), porque ainda não houve sincronização, — mas ter de “imaginar”, é tudo o que pode haver de mais inútil, para um usuário, em especial se for leigo em TI.

Proposta apresentada pelo Unison após a comparação da partição de origem com a pasta de destino

Mas, usuário teimoso não pede para sair. Clicado “Ok”, Unison começou imediatamente a procurar alterações (Looking for changes), — e após 48 minutos apresentou a lista de todas as pastas existentes em “F:\”, com setas verdes apontando para a direita, — sinal de que não existia nada “mais novo”, no destino, — nem nada que não existisse na origem.

Ícones na Barra de ferramentas permitem alterar, — cada linha da lista, ou várias, ou todas, — para “Skip” (pular), “Right to left” (inverter), “Left to right”, “Merge”.

Estavam desabilitados, naquele caso, os ícones “Diff” (ver as diferenças), e “Details” (detalhes).

Mais à direita, ícones “Go”, — executar as operações sugeridas (e/ou editadas), — “Rescan” (examinar tudo de novo), “Change profile” (escolher outro perfil).

Unison copiando 175 mil arquivos (135,7 GiB) para uma pasta na unidade externa SSD

Disparei “Go” e, após 1 h 55 min, concluiu-se a cópia inicial de todo o conteúdo da partição “F:\” para a pasta escolhida na partição “Terabyte” do drive externo SSD.

Fiquei, então, com um perfil “Default” plenamente habilitado para desempenhar regularmente a primeira metade das tarefas de backup.

Sem conseguir criar um novo perfil, — tentativas sempre acabando em crash, — cheguei a adicionar mais 2 pastas ao perfil “Default”, para ver se seriam aceitas como nova origem e novo destino, mas não é assim que as coisas funcionam:

Fatal error

Wrong number of roots: 2 expected, but 4 provided (/media/flavio/F, /media/flavio/Terabyte/Backup/part_F, /media/flavio/E, /media/flavio/Terabyte/Backup/part_E)
(Maybe you specified roots both on the command line and in the profile?)

Embora “fatal”, esse erro não causa fechamento abrupto do Unison.

Duplicando e renomeando perfis do Unison no Dolphin

A solução encontrada foi abrir a pasta “/home/flavio/.unison/”, fazer cópias do perfil “Default”, — e editar os parâmetros pelo Kate, — em modo usuário, pois o Unison não estava rodando como Root:

cp default.prf backup_E.prf
cp default.prf backup_F.prf

Com pequenas alterações de “F” para “E”, o perfil que faltava ficou assim:

# Unison preferences
fat = true
root = /media/flavio/E
root = /media/flavio/Terabyte/Backup/part_E

Por fim, o perfil “Default” foi novamente alterado, e excluída qualquer referência ao drive externo SSD, — que não permanece plugado a maior parte do tempo, — caso contrário, seria impossível abrir o Unison, para conferir alguns detalhes deste relato:

# Unison preferences
root = /home/flavio/Wallpapers/
root = /media/flavio/Home2/flavio/Wallpapers/

Sumário → Detalhes, ao final da sincronização pelo Unison

Porém, mesmo algo tão inocente quanto sincronizar wallpapers entre as partições “Home1” e “Home2” acabou apresentando surpresas, — por exemplo, um arquivo “.directory” (oculto) com especificações que são só do Kubuntu.

Desmarcado (“Skip”) o arquivo oculto, foi feita a sincronização, de modo que os mesmos wallpapers agora possam ser encontrados tanto na “Home1” quanto na “Home2”.

Unison identifica o que foi deletado, e propõe “propagar as mudanças” para a pasta de destino

Em seguida, foram deletados alguns arquivos duplicados, — cujos nomes haviam sido alterados só no Kubuntu ou só no Linux Mint, — e o Unison identificou a mudança com perfeição, propondo deletar as duplicatas também na outra pasta.

Ou seja, a “bi-direcionalidade” não levou ao erro de recriar o que havia deletado, — coisa que agora é lógica e óbvia, mas até então, para um leigo absoluto, não era certeza.

Instalação


Unison instalado no Linux Mint, para verificação: — sem nenhum “perfil”

Inicialmente, foi instalado no Kubuntu 16.04 LTS o pacote “unison (2.48.3-1ubuntu1)”, — sem interface gráfica, — por engano.

Constatado o engano, foi instalado o “unison-gtk (2.48.3-1ubuntu1)”, localizado e instalado pelo Synaptic, — que não apresentou dependências, embora seja recomendado instalar também “openssh-client:i386”, e sugerido “unison-all-gtk”.

A simples instalação do “unison-all-gtk” não impediu que o “Profile creation” continue fechando abruptamente o Unison, tão logo se clica em qualquer opção de pasta de origem ou destino, — inclusive “Other”.

A instalação do “openssh-client:i386” implica remover “openssh-client”, — por isso, foi testada inicialmente a instalação do “ssh-askpass-gnome”, — o que também não fez diferença no comportamento irregular.

Por fim, foi instalado “openssh-client:i386”, — com remoção do “openssh-client”, — também sem alterar a rotina de encerramento abrupto.

Depois disso, o Synaptic passou a recomentar “openssh-client”, — o que implica em remover “openssh-client:i386”, — um loop sem fim, portanto.

Como última possibilidade, foi removido “unison” (sem interface), — que não é requisito para o “unison-gtk”, — mas tampouco alterou a situação.

Unison no Linux Mint: — mesma “proposta” do Kubuntu para as pastas “Wallpapers”

Para verificação, no Linux Mint 18 KDE foram instalados, — simultaneamente, via Synaptic, — “unison (2.48.3-1ubuntu1)” + “unison-gtk (2.48.3-1ubuntu1)”.

Ao abrir pela primeira vez, no Linux Mint 18 KDE, “unison-gtk” não trazia nenhum “Perfil”, — mas o “Profile creation” funcionou perfeitamente, até o final, — e a comparação das pastas “Wallpaper” das “home1” e “home2” apresentou a mesma proposta de sincronização. — Apenas, não mandei executar, pois havia reservado essa tarefa para o Kubuntu 16.04 LTS.

Até onde chega a compreensão de um usuário leigo, as diferenças mais evidentes são: — (a) o Mint permanece com Kernel 4.4.0-21, enquanto o Kubuntu incorporou a revisão 4.4.0.51 minutos antes da instalação do Unison, e agora já está na 4.4.0-53, mas persiste o problema; — (b) alguns traços de origem Gnome, um pouco mais pronunciados no Mint KDE do que no Kubuntu; — (c) equipe maior e mais “profissional” no Kubuntu vs. equipe menor e mais “artesanal” no Mint.

Este é o primeiro item, em que o Kubuntu 16.04 LTS fica nitidamente atrás do Linux Mint 18 KDE, — em geral, é no Kubuntu 17.04 Zesty Zapus (development branch), no Debian testing, e até no KDE Neon 4.8, que (ainda) não consigo realizar algumas tarefas, — porém o backup também é a única tarefa que geralmente não tento fora do Kubuntu, para evitar conflitos ou confusões.

Para leitura


Manual do luckyBackup no Help (F1), com texto minucioso e fartamente ilustrado

À primeira vista, portanto, — nesse nível intuitivo (“tatear às cegas”), sem maiores conhecimentos, — o Unison atende razoavelmente bem a 2 ou 3 “tarefas”, — se não forem muito frequentes, — devido à necessidade de trocar de “perfil” ao final de cada uma, para realizar a próxima.

Sob esse aspecto, é muito mais prático usar o luckyBackup, — onde você pode incluir 20 ou 30 “tarefas” em um único “perfil”, — e resolver tudo com um clique só.

É claro que há maneiras de automatizar tudo isso, no Unison, — e no luckyBackup, também, — inclusive marcando hora de madrugada (se a máquina permanece ligada), ou “ao inicializar”, por exemplo.

Há vários anos, desisti da automação, por 2 motivos principais: — (a) Incerteza sobre partições eventualmente não-montadas, como é o caso agora da unidade externa SSD; e — (b) Retardar o backup de um punhado de arquivos novos ou editados nas últimas 24h ou 48h é muito menos “crítico” do que excluir automaticamente o backup de inúmeros arquivos, deletados sem medir as consequências (muitas vezes, o backup “atrasado” resgatou a imprudência).

O segundo motivo poderia ser amenizado, — digamos, por uns 4 dias, — pela manutenção automática de até 4 “snapshots”, desde que o espaço exigido atenda à relação custo / benefício:

Snapshots to keep
Every time a task is run the source data are backed-up as they are at that specific time.
This is called a snapshot !!
luckyBackup can hold a number of snapshots so that it is possible to revert to any one of them.
Define the maximum number of snapshots you wish to keep, by clicking on the arrows of the spin-box.
If that number is reached, older snapshots will be deleted when the task is run again.
The default number of snapshots to keep is 1.

Fica patente que falta ler muito sobre o Unison, — e sobre o luckyBackup.

Para facilitar a consulta, foram reunidos em local de fácil acesso alguns documentos de ajuda encontrados no Help, no comando “unison -doc” e em “/usr/share/doc”:

Unison-doc.txt
Unison-Help_Basic-concepts.txt
Unison-Help_Running-Unison.txt
Unison-Help_Tutorial.txt
Unison-Manual_usr-share-doc-unison.txt

Sobre o luckyBackup, o Help (F1) concentra o máximo de informações em um “Manual”, fartamente ilustrado, com 88 KiB de texto minucioso.

A resolver


Esse backup completo das 2 partições, — além de muito mais simples, — é o que fará mais sentido, quando for instalado um novo HDD interno de 1 Terabyte.

A ideia (por enquanto) é fazer o backup frequente das partições “E:\” e “F:\” para o novo HDD interno, — e periodicamente para o SSD externo.

Isso deverá substituir a rotina atual, — de clonar apenas algumas pastas escolhidas, — e por consequência, vai liberar espaço das partições “home1” e “home2”, praticamente duplicando a capacidade atual das partições de trabalho.

Além disso, várias pastas das partições “E:\” e “F:\”, — que não são de trabalho, mas apenas para guarda de acervos, — também poderão ser ser movidas para o novo HDD, com cópias no SSD.

Teoricamente, o novo HDD será mais rápido, — além de ser Sata3, — porém as portas da placa-mãe ainda são Sata2, o que limitará sua taxa de transferência.

Em geral, pensamos em usar sempre o HDD mais rápido, e relegar os HDDs mais lentos para tarefas secundárias, — mas cabe pensar se o backup se enquadra em “secundário”. — Fazer backup de 2 menores em 1 maior parece a coisa mais simples, ao passo que o inverso sempre depende de previsões (falíveis) sobre o provável crescimento de 2 grupos de pastas.

Sequência da reorganização



Pré-história


“Desde os tempos paleolíticos, o homem das cavernas…”

O primitivo Apple II+ (8bit), com 64KB RAM e apenas 1 “Floppy disk drive” (FDD) de 5¼’’, — onde precisava ser mantido o diskette com o sistema operacional, — adquirido em 1986, não alimentava luxos de backup. Mesmo com o segundo FDD (1987), o “espaço” para manobras era acanhado. No mínimo, implicava em tirar e colocar 2 diskettes, alternadamente, inúmeras vezes (se é que isso era possível; não lembro). Cada um, comportava 120 ou 130 KB (se não me engano). Com um furador de papel, podia-se abrir um “rasgo” na segunda lateral da “capa”, para permitir gravação do outro lado. Fechar esses “rasgos” laterais com uma etiqueta autocolante impedia nova gravação, por segurança.

Manobra especial, já com placa CP/M (1987), era carregar o sistema + aplicativo (dBase II, Wordstar, Calcstar), em seguida deletar o aplicativo, — mantendo o “overlay”, que continuava necessário, — e no espaço assim liberado, copiar arquivos do outro diskette, — que em seguida seria substituído por um terceiro, para gravar nele o backup. Pouca coisa chegava a merecer tanto esforço, — e de qualquer modo, nada pôde ser preservado, ao adquirir o PC-XT (1990), pela demora em migrar. — Corria a lenda de que, no Serpro, algum maluco ainda mantinha um esquema para cópia de diskettes Apple II+ / PC-IBM, mas não consegui localizar tal pessoa. Serviu de lição, para nunca mais ficar estacionado em um beco-sem-saída tecnológico. Cadastro de assinantes, aplicativos dBase II (gerador de etiquetas) etc. tiveram de ser impressos em papel, pelo Apple II+, — e digitados novamente, no PC-XT.

O PC-XT (16bit), com 640 KB RAM + HDD de 20 MB + 2 FPP (5¼’’ e 3½’’), a partir de 1990, e seus sucessores 286, 486 e Pentium II deixaram muito mais backups, — arquivos Xerox Ventura Publisher, MS-DOS Word, WinWord, dBase III, AutoCAD etc., — que permaneceriam compatíveis até hoje, se ainda houvesse aparelhos de Floppy no mercado. A lição aprendida fez migrar, o quanto antes, para “discos ZIP” (Iomega Zip Disk), e em seguida para CD. O que ainda se aproveita, há muito tempo já está em HDD, — com backup em outro HDD, e agora também no SDD (além dos CDs / DVDs intermediários). É um acervo “morto”, fixado no tempo, — exceto pelas muitas conversões e edições que já foram feitas, desde então, e que não há motivos para descartar, sob pena de algum dia precisar reconverter e reeditar a partir dos originais. Isso inclui, também, um conjunto de “macros” do Word (guardados em “c/users/ flavio/ Application Data/ Microsoft/ Modelos/ normal.dot” do Wine). A conversão também depende do Wordpad, único aplicativo encontrado até agora, capaz de identificar (e substituir) a codificação do “á” minúsculo do MS Word / Xerox Ventura Publisher, — salvo algum comando cabalístico do Linux, que ainda não descobri.

Uma terceira “camada geológica” de backups é formada por quase 200 CDs / DVDs, usando (e às vezes misturando) 2 metodologias diferentes: — (a) Cópias de pastas ou subpastas completas, zipadas ou não, em diferentes momentos dos últimos 15 anos, abrangendo todo o conteúdo das partições de documentos do Windows, desde 2000; e (b) Cópias apenas dos arquivos modificados “desde o backup anterior”, localizados pela busca avançada do Explorer (CTRL-F) e zipados em massa, para preservar suas posições na “árvore” de pastas. — Lidar com tudo isso, diretamente, é um tal de “ejeta-CD-coloca-DVD” extremamente enjoado. Até uns 10 anos atrás, o DSearch (DiskSearch, Tenebree Software) ajudava. Depois, simplifiquei a vida, gerando TXTs com o conteúdo de cada disco, pelo comando (Windows) “dir h: /s > 097_CD_Label.txt”, — variando a numeração e a “label”. Uma busca por “string” no conteúdo, na pasta onde estão esses TXTs, localiza todos os backups de qualquer arquivo, cujos nomes mantêm certo padrão, ao longo do tempo. Aos poucos, os arquivos que interessam, foram sendo copiados para o HDD, e é cada vez mais raro precisar buscar mais alguma coisa nos antigos backups em CD / DVD.

História antiga


“Já na antiga Grécia…”

O luckyBackup foi instalado em 12 Mai. 2012, simultaneamente com o Komparator, Unison-gtk, Sitecopy e Krusader, escolhidos rapidamente, em uma busca no Synaptic, para ver qual atendia melhor. A primeira “tarefa” do luckyBackup foi configurada às 13:55, e a cópia inicial se completou em 14 minutos. Foram configuradas mais algumas “tarefas”, padronizando as opções, e registrei que ele colocava arquivos ocultos nas pastas das partições Fat32 (Windows). Uma anotação da época fala em um “controle”, visto de passagem, que talvez evitasse isso, mas pode ter sido só impressão. Hoje, não encontro arquivos ocultos do luckyBackup nas partições Fat32 (provavelmente, só ocorre quando a “sincronização” é feita nos dois sentidos). Também ficou clara a necessidade de assegurar a prévia montagem das partições envolvidas, — automaticamente, ou à mão. Um relato bastante resumido foi publicado em 14 Mai. 2012.

Naquele momento, ainda imaginava a possibilidade de editar os mesmos arquivos, indiferentemente, tanto nas partições do Windows quanto na “/home” do Kubuntu (Home1), — por isso, adotei a opção de sincronizar as pastas de documentos nos 2 sentidos.

Na prática, isso impunha backups excessivamente frequentes, — já que o Windows não podia acessar a partição “/home” do Kubuntu, em busca de alguma alteração feita poucas horas antes, — além do risco de fazer alterações em ambas as cópias de um mesmo arquivo, inadvertidamente, e a última alteração sobregravar a outra, ao disparar o backup. Mas o mais chato, era no final do Horário de verão, — quando as horas das duas cópias se desencontravam, — a menos que fizesse uma alteração no Windows, que não me animei a tentar. É possível que tenha feito alguma alteração nos dois Linux (este ano, o Linux Mint 17.3 foi flagrado fora do padrão UTC, mas não sei se “herdou” isso de alguma coisa feita em 2012, ou se foi burrice durante a instalação, em 2016).

Em 19 Ago. 2012, o luckyBackup foi completamente(?) removido, e reinstalado, — nenhuma anotação do motivo. — Ao abrir novamente, as antigas “tarefas” apareceram intactas, porém eu havia deletado as pastas da “Home1” (Kubuntu), por motivos que também não anotei. Foi criado um novo “perfil”, e nele recriadas as “tarefas”, apontando para novas pastas.

O Unison-gtk 2.40.65 foi utilizado regularmente de Set. 2012 até Ago. 2014, — ou seja, na “vigência” do Kubuntu 12.04, — com um intervalo entre Fev. e Ago. 2013, de acordo com “~/.unison/unison.log”.

É possível que as “tarefas”, — alternando “perfis” manualmente, — fossem disparadas ao final de determinados trabalhos, cujos arquivos considerava mais importantes. Em 10 Set. 2012, foram sincronizadas 7 pastas, — mas no dia 14, apenas uma, com textos referentes aos séculos XVIII e XIX. Em 20 Out. 2012, apenas 2 pastas, ambas sobre as locomotivas live-steam do Deo Espírito Santo, — mas em 24 Out., nada menos que 9 pastas, talvez percorrendo manualmente todo o conjunto de “tarefas”, com material acumulado. Mas é difícil ter certeza.

Em 1º Ago. 2013, voltei a substituir o luckyBackup pelo Unison. — Nenhuma anotação sobre o motivo, — apenas, que deletei as pastas anteriores, e criei outras, com nomes diferentes, em outro “local” da “Home1”.

Em 24 Ago. 2014, foi feito upgrade do Kubuntu 12.04 para 14.04. Três semanas depois, em 13 Set. 2014, acabei decidindo reinstalar o Kubuntu 14.04, — e a lista de pacotes instalados em seguida, pelo Synaptic, começa pelo Unison-gtk. Só que, não funcionou. Em 1º Out. 2014, há várias anotações de uma tentativa de decifrar o mistério (permissões, path etc.), sem resultado.

A impossibilidade de mergulhar no estudo, — isso não era a única coisa a exigir pesquisa e leitura, às voltas com a migração para o Kubuntu 14.04, — fez com que o problema se arrastasse por mais 2 meses (120 dias sem backup automatizado). Em 1º Dez. 2014, o Unison-gtk foi reinstalado e removido completamente, nada menos que 3 vezes. Em seguida, o luckyBackup voltou a ser instalado, removido completamente, e reinstalado, — e voltou a ser usado, desde então.

Quase todos os logs hoje existentes em “~/.luckyBackup/” são de 1º Dez. 2014, — exceto dois, datados de Set. e Mai. daquele ano. — [Também há um “luckyCron.txt” mais antigo, de 14 Mai. 2012. — De 2016, apenas um “default.profile” em branco (0 B), de 24 Abr., quando foi instalado o atual Kubuntu 16.04; e um “settings.ini” de 6 Jun., embora tenha feito inúmeros backups depois desse dia].

Ainda em Dez. 2014, foi feita uma “limpeza” de dezenas (ou centenas?) de arquivos ocultos nas partições do Windows, infelizmente não documentados (o Windows localizou e deletou sem dificuldade). Se isso era necessário, até hoje não sei. No próprio Kubuntu 14.04, em 20 Dez. 2014, também foram deletados outros arquivos ocultos, — um conjunto para cada “tarefa”. As anotações da época são resumidas demais, e pouco esclarecem:

Removido todos os dados antigos do registro instantâneo
Removendo /root/.luckyBackup/snaps/default-site VFCO-20141219081905.changes.log
Removendo /root/.luckyBackup/logs/default-site VFCO-20141219081905.log
Removido todos os dados antigos do registro instantâneo
Removendo /root/.luckyBackup/snaps/default-workflow VFCO-20141219081922.changes.log
Removendo /root/.luckyBackup/logs/default-workflow VFCO-20141219081922.log
(etc.)

Parece que a partir de 20 Dez. 2014 o problema ficou resolvido, — e não cometi mais burradas, — mas é uma pena não ter anotações claras do quê possa ter aprendido a não fazer (se é que aprendi), para assegurar que não volte a fazer no futuro.

Em 1º Ago. 2015, foi instalado um segundo Kubuntu 16.04 LTS no lugar de “Linux2”, — absolutamente igual ao “Linux1”, exceto por ser “i386” (enquanto o “principal” era “amd64”), — e imediatamente foi instalado o luckyBackup, também nele (por hábito). Porém, acredito que nunca foi colocado em uso.

Entre 20 e 27 Jan. 2016, chegou a ser usado um segundo luckyBackup, — instalado no Linux Mint 17.3, — para sincronizar apenas 2 pastas, que não faziam parte do backup regular pelo Kubuntu.

Em 12 e 13 Fev. 2016, foram alteradas as “etiquetas” (Label) das partições Fat32, — e editadas as “tarefas” do luckyBackup, simplificando o “path” nos comandos, — que até então usavam identificadores UUID, incômodos de decifrar, no meio de qualquer tarefa.

Não lembro de qualquer problema, ao instalar o Kubuntu 16.04, em 24 Abr. 2016, e novamente o luckyBackup, no mesmo dia. — Naquele momento, tudo já estava sendo minuciosamente registrado em centenas de PrintScreen, TXTs etc. (se houve algo digno de nota, vai acabar aparecendo).

De 1º a 28 Mai. 2016, o Windows XP começou a ser “evacuado”, — pela eliminação sistemática de grupos de arquivos, tanto em “C:\” (programas desinstalados), quanto em “F:\” (velhos Photoshop), — e sucessivos esvaziamentos da Lixeira, devidamente documentados. Ao final, foi rodado o luckyBackup (após mais algumas verificações), para liberar espaço também na “Home1”.

Felizmente, o Windows pôde ser eliminado, em 29 Mai. 2016, e agora todos os Linux seguem o padrão de hora UTC no sistema, — só tinha “estragado” a configuração do Mint 17.3, mas o Debian tanto reclamou, que o erro foi percebido e corrigido. — Fato é que o luckyBackup continua funcionando bem, até hoje.

Sequência da reorganização



___________
• Backups realizados em 29 e 30 Nov. 2016, no Kubuntu 16.04 LTS, com uma pequena ajuda do Linux Mint 18 KDE.
• Levantamento, relato, tratamento de imagens e publicação inicial em “Live DVD” (Pendrive 8GB) Knoppix 7.7.1, nos dias 2 a 4 Dez. 2016.
• Uma chuva com relâmpagos e risco de eventual queda da rede elétrica, na tarde de 4 Dez., fez encerrar a sessão “Live DVD” (Pendrive 8GB) Knoppix 7.7.1, e prosseguir no Kubuntu 16.04 LTS, instalado no HDD.

— … ≠ • ≠ … —

Ferramentas &tc.


Postado por Mboaba às sábado, dezembro 03, 2016 0 comentários
Marcadores: , , , , , , , , , , , , , ,
Assinar: Postagens (Atom)