Translate

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
Marcadores: , , , , , , , , , , , , , ,

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)