Translate

Mostrando postagens com marcador Fonte ATX. Mostrar todas as postagens
Mostrando postagens com marcador Fonte ATX. Mostrar todas as postagens

quinta-feira, 22 de dezembro de 2016

Migrando sistemas Linux para um novo disco rígido

Clonagem do Kubuntu 17.04 Zesty em nova partição, via “copy / paste” do GParted em Live Knoppix
Clonagem do Kubuntu 17.04 Zesty em nova partição, via “copy / paste” do GParted em Live Knoppix ✅ 

A migração dos sistemas Linux para HDD de 1 Terabyte deverá ser feita, — como das outras vezes, — de modo gradual, balanceado e sem apavoramento, ao longo dos meses.

Não existe motivo para fugir correndo dos antigos HDDs de 320 GB, muito menos jogá-los no lixo. — Pelo contrário, é preferível que os sistemas mais “usáveis” e “confiáveis” — Kubuntu LTS e Linux Mint, — fiquem em HDDs diferentes, por segurança contra falhas.

Urgente, era transferir o Kubuntu 17.04 Zesty Zapus, — do SSD* externo para o novo HDD, — uma vez que a unidade “portátil” não fica o tempo todo plugada (ocupando uma saída USB). Mas a existência de um sistema instalado nele exigia plugar com frequência, para atualizar o Grub, após cada upgrade ou correção de Kernel em qualquer outro Linux.

O novo “backup total”, — em substituição aos antigos backups, de apenas algumas pastas, — também ficará melhor no HDD de 1 Terabyte (com cópia periódica para o SSD* externo de 1 Terabyte).

Sequência da reorganização



HDD e Fonte ATX


As especificações do HDD de 1 Terabyte Seagate indicam a necessidade de quase 13W

20 Dez. 2016 - Segundo todos os cálculos e parâmetros encontrados nos melhores sites e blogs, a fonte de energia ATX “provisória”, de 220W, não era digna de confiança, para as exigências do hardware existente, — pior ainda, com o acréscimo do novo HDD de 1 Terabyte. — E como ainda não foi encontrada manutenção ou substituição para a ventoinha da antiga fonte ATX de 800W, ela foi deixada de lado, por enquanto. Em seu lugar, foi instalada uma fonte ATX de 500W.

16:06 - No entanto, foi feito um teste de 2 horas, — após instalar o HDD de 1 Terabyte, — antes de instalar a fonte ATX de 500W.

Nessas 2 horas, não chegou a ser praticado nenhum exagero, — nenhuma tarefa de elevado consumo de energia, — apenas o particionamento do HDD de 1 Terabyte, e o feijão-com-arroz de cada dia.

Porém, de acordo com o Xsensor, não houve alteração alguma nos níveis de energia, — a saída Vcore continuou oscilando entre 1,19V ~ 1,28; a saída +3,3V continuou oscilando em torno de 3,31V; a saída +5V continuou oscilando em torno de 4,97V ~ 4,99V; e a saída de +12V continuou oscilando em torno de 12,25V.

Especificações da fonte ATX de “500W”

18:09 - Instalada a fonte ATX de 500W, a saída Vcore mantém a mesma faixa de oscilação; a saída +3,3V passou oscilar entre 3,31 ~ 3,33V; a saída +5V passou a oscilar em torno de 5,02V ~ 5.04V; e a saída de +12V passou a oscilar entre 12,25V ~ 12,30V.

Esses novos números, — como, aliás, também os anteriores, — estão longe dos limites indicados:

flavio@Linux2:~$ sensors
atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage:      +1.19 V  (min =  +0.85 V, max =  +1.60 V)
 +3.3 Voltage:      +3.33 V  (min =  +2.97 V, max =  +3.63 V)
 +5   Voltage:      +5.02 V  (min =  +4.50 V, max =  +5.50 V)
 +12  Voltage:     +12.30 V  (min = +10.20 V, max = +13.80 V)

Particionamento


Primeiro passo: — Criar tabela de particionamento do HDD, no GParted. — Ignore o aviso, neste caso

O particionamento do HDD de 1 Terabyte foi feito pelo GParted, — em Live Knoppix em Pendrive, com “persistência”, — por 2 motivos principais:

(a) O Live Knoppix não monta automaticamente as demais partições e dispositivos conectados, — até para reconhecer um CD colocado na bandeja, exige empenho pessoal; e

(b) Já carrega normalmente como “Administrador” (Root). — É muito prático, para manutenção do computador e/ou dos sistemas instalados.

Podem-se usar outras ferramentas “Live CD”, — GParted Live, por exemplo, — mas o Live Knoppix em Pendrive, com “persistência”, oferece muito mais comodidade (Dolphin, Chromium, Kate etc.), para conferir detalhes do hardware e tirar dúvidas, além de uma tonelada de outras ferramentas, em caso de necessidade.

Localização física das portas SATA na Placa Mãe, — fora da sequência numérica

Observe, no canto superior direito do GParted, a seleção de “/dev/sdc”, — localização do terceiro HDD, — provavelmente, porque foi conectado na terceira porta SATA da Placa Mãe, que já estava reservada para ele.

  • O Drive CDROM está conectado na porta 4, porém jamais se identificou como “sdd”, — e agora, isso parece caber ao SSD externo, sempre que plugado, independente de em qual slot USB. — Parece que o Pendrive sempre se identifica como “sde”, — ou “sdd”, (só) quando o SSD não está plugado. Ainda não foi verificado com +1 Pendrive, uma vez que os outros 2 slots estão ocupados pelo Teclado e pelo Mouse.

Menu → Device → Create partition table, no GParted

O primeiro passo é criar uma “tabela de particionamento”, — sem a qual, não se pode nem começar, — e ignorar o aviso de que isso vai “apagar todos os dados”.

Essa advertência é importante, quando o disco rígido já tem partições, dados, sistemas etc., — mas neste caso, ainda não há nada no HDD.

Na Barra de Menu → Device → Create partition table.

Partições primárias e estendida do novo disco rígido

A partir dos erros e acertos observados nos particionamentos anteriores (HDDs e SSD), foram criadas 3 partições primárias de 25 GB (cada), para futura instalação de sistemas Linux, — e o espaço restante foi destinado a uma partição estendida, — devido ao limite de 4 partições (primárias ou estendidas).

Essas operações não são demoradas, — o que parece demorar mais, é o exame dos dispositivos, que volta a ser feito pelo GParted, depois de “aplicar” qualquer modificação. — Por isso, vale a pena agrupar várias operações, e “aplicar” todas de uma vez.

Partições lógicas do novo disco rígido

Dentro da partição estendida, foram criadas mais 3 partições de 25 GB para instalação de sistemas Linux, — e uma partição de 751,5 GB para “Backup1”, — após reservar 30 GiB no final, para 6 partições Swap.

Com isso, todos os 4 sistemas atualmente instalados nos 2 HDDs de 320 GB já poderiam ser transferidos, em tese, para o HDD de 1 Terabyte, — porém não existe necessidade de fazer isso, nem pressa desesperada.

A “numeração” desses futuros sistemas Linux (e respectivos Swap) foi feita de 11 a 16, — e não na sequência “natural”, de 5 a 10, — por não ter certeza de como seriam classificados e exibidos em diferentes softwares. Há situações em que “Linux10” é exibido antes de “Linux2”, por exemplo.

Limpeza de Kernel


Dolphin aberto como Root para deletar Kernel do antigo Linux Mint 17.3

Como parte da reorganização geral, foi deletado o Kernel 3.19.0 do antigo Linux Mint 17.3 Cinnamon, — que sobreviveu, graças à instalação “heterodoxa” do Linux Mint 18 KDE (Beta).

Opções avançadas do Linux Mint, no Grub, — finalmente sem Kernel 3.19

Carregava, — por incrível que pareça, — mas não tinha a menor utilidade, exceto “sujar” as Opções avançadas do Linux Mint no Menu de inicialização. E não podia ser removido pelos meios normais, pois não aparecia no mintUpdate.

Por via das dúvidas, foi apenas mandado para a Lixeira do Administrador (Root), — de modo que possa ser restaurado, se necessário. — Mas, após 3 dias, o Linux Mint 18 KDE continua muito bem, sem ele.

Depois disso, bastou rodar “sudo update-grub”, para detectar os sistemas instalados, — com suas opções de Kernel, — e atualizar o Menu de inicialização.

MemTest86 do Linux Mint 17.3

O MemTest86, — também sobrevivente do Linux Mint 17.3 Cinnamon, a julgar pela data, — continua funcionando bem, a partir do Menu de inicialização.

Não haveria motivo para não funcionar, — ele é independente, roda antes de ser carregado qualquer Linux. — Em todo caso, basta usar o Live CD MemTest86 v. 7.1.

Limpeza do SSD* externo


Reaplicando rótulos após formatar as partições Linux6 e Linux7, no SSD externo

Duas partições do “disco” SSD* externo, — Linux6 e Linux7, — tinham sofrido tentativas de instalação do Knoppix, que nunca chegaram a ser muito “usáveis”, e já estava na hora de eliminar.

Isso foi feito pela simples formatação dessas partições, — e reaplicação dos mesmos rótulos.

Assim, “Linux6” deixou de ser detectado e automaticamente incluído no Menu de inicialização, a cada “sudo update-grub”.

Limpeza do arquivo de configuração “/etc/grub.d/40_custom”, via Dolphin / Kate em modo Root

No caso da partição “Linux7”, o método tentado para instalar o Knoppix envolveu edição do arquivo de configuração “/etc/grub.d/40_custom” do Linux Mint, — por isso, foi necessária uma limpeza nele, para deixar de inserir aquelas entradas no Menu de inicialização, automaticamente, a cada “sudo update-grub”.

Clonando sistema Kubuntu


Redimensionando a partição do Kubuntu 17.04 Zesty Zapus de 40 GiB para 25 GiB

Faltava transferir o Kubuntu 17.04 Zesty Zapus (development branch), — instalado na partição “Linux5”, de 40 GB, do SSD externo, — que não fazia sentido deletar, e depois instalar outra vez no novo HDD.

Um método “troglodita” de clonar essa partição de sistema, — que não tem “/home” separada, — era usar o comando “dd”.

Só que, para isso, a partição de destino precisava ser igual ou maior do que a partição de origem, — mas acontecia exatamente o contrário. — A partição de destino tinha apenas 25 GB, contra 40 GiB da partição a ser clonada (só 8,34 GiB usados).

Relatório das operações abrangidas pelo redimensionamento da partição de sistema de 40 GiB para 25 GiB

Poderia tentar o Partclone, — que oferece “backup used blocks”, mas “it seems like you've found another tool that requires the same device size”, — ou redimensionar a partição de origem para 25 GiB, com algum risco de perda de dados no próprio “original”.

Um backup em arquivo “.img” manteria o tamanho original, — permitiria recuperar eventuais perdas, mas levando de volta ao mesmo beco-sem-saída, — ao custo de mais algum tempo.

No entanto, o Zesty Zapus não é o sistema “principal”, nem o “alternativo”, — sua perda seria um incômodo, mas não um desastre, — e se esse caminho desse certo, pouparia várias horas de pesquisa e aprendizado.

Assim, redimensionar a partição de origem foi o caminho escolhido, — e o GParted se encarregou das operações envolvidas, — como realocar blocos, atualizar referências etc., — para que continuasse operacional.

Copiando e colando uma partição na outra, pelo GParted, em Live Knoppix

Felizmente, antes de completar a montagem do comando “dd”, — ainda faltava um longo e demorado estudo dos parâmetros mais adequados (morrendo de medo de errar), — foi descoberto o “copy & paste” do GParted, que poupou muito tempo e pesquisa.

Relatório final da clonagem da partição de sistema do Kubuntu 17.04 Zesty Zapus, — em 4’32‘‘

O clone da partição de sistema do Kubuntu 17.04 Zesty Zapus foi concluído em 4 minutos e 32 segundos, — e o relatório do GParted dá uma boa ideia das operações envolvidas, — inclusive os comandos usados por trás da interface gráfica.

Alterando o rótulo da nova partição Kubuntu 17.04 Zesty Zapus, para evitar duplicidade

Para testar na prática o clone do Kubuntu 17.04 Zesty Zapus, ainda faltavam algumas providências, — por exemplo, rotular sua partição como “Linux16”, — pois não era conveniente ter 2 partições com o mesmo rótulo “Linux5”.

Atribuindo nova partição de Swap ao clone do Kubuntu 17.04 Zesty Zapus

Outra providência, era localizar o identificador UUID da partição Swap16, e atribuí-lo ao clone do Kubuntu 17.04 Zesty Zapus, editando seu arquivo de configuração “/etc/fstab”.

Edição do “/etc/fstab” no Kate, chamado via Dolphin aberto como “root”, no Linux Mint 18 KDE

Essa operação foi feita no Linux Mint 18 KDE, — a ser usado em seguida, para atualizar o Grub. — A partição “Linux16” foi aberta no Dolphin como “root”, para agilizar a edição pelo Kate.

Detectando o clone do Kubuntu 17.04 Zesty Zapus e atualizando o menu do Grub

Depois disso, o comando “sudo update-grub” detectou os sistemas instalados, — inclusive o clone do Kubuntu 17.04 Zesty Zapus, — e atualizou o Menu de inicialização.

Partição do Kubuntu 17.04 Zesty Zapus com identificador UUID duplicado do original

A própria partição “Linux16”, — clonada de “Linux5”, — também apresentava identificador UUID duplicado.

Grub com o novo e o antigo Kubuntu 17.04 Zesty Zapus

Mas, ao invés de perder tempo com isso, apenas foi desplugado o drive SSD externo, — e seu UUID seria automaticamente alterado ao formatar a partição “Linux5”, mais tarde, — se o clone em “Linux16” carregasse com sucesso.

Clone do Kubuntu 17.04 Zesty Zapus carregado, — e já recebendo atualizações

O clone do Kubuntu 17.04 Zesty Zapus carregou com sucesso, — e desde esse momento, passou a ser utilizado e atualizado como se fosse o mesmo, — aliás, o único, dali por diante.

Conferindo as funcionalidades do clone do Kubuntu 17.04 Zesty Zapus

Foram conferidas as principais funcionalidades, — de um ponto de vista particular, específico, — e até o momento, não apresentou qualquer diferença, em relação ao original.

Redimensionando a partição original (reformatada), reaplicando a Label, — e atribuindo novo UUID

De volta ao Live Knoppix, foi usado o GParted para formatar a partição original do Kubuntu 17.04 Zesty Zapus.

Em seguida, a partição (Linux5) foi redimensionada, — de 25 GiB para 40 GiB, outra vez, já que não adiantava deixar 15 GB sem uso, — com reaplicação do rótulo “Linux5”, e atribuição de outro identificador UUID, para ver como é isso. — De fato, não precisava pois, ao formatar, já tinha alterado o UUID.

GParted do Knoppix, incapaz de lidar com partições exFAT

Algumas operações tiveram de ser feitas no Linux Mint 18 KDE (onde optei por instalar o KDE Partition Manager, para comparação), — devido à inconveniência de instalar pacotes adicionais (exfat-fuse) no Knoppix, — concebido como “Live CD / DVD”, não como “distro” para instalar e atualizar com facilidade.

Alterando a Label de uma partição exFAT no KDE Partition Manager

Foi o caso, por exemplo, da partição exFAT do drive SSD externo, — cuja Label merecia ser alterada para “Backup2”, — pois será uma cópia de reserva do ”Backup1”, criado no novo HDD de 1 Terabyte.

Montagem automática de partições


KDE → Configurações do sistema → Montagem de partições adicionais

A clonagem do Kubuntu 17.04 Zesty Zapus e a reorganização dos Backups em novas partições exigem reconfigurar as partições adicionais que gostaria de ver montadas automaticamente, no início de cada sessão, — inclusive, para monitorar sua ocupação, pelo Conky:

  • Linux1 a Linux4, e Linux16, — arquivos dos diferentes sistemas

  • Home1 e Home2 — documentos e configurações

  • “E:\” e “F:\” do antigo Windows (Fat32) — documentos de trabalho


Partição “da /home” não é a mesma coisa que “a /home”

Lembrando, — por “adicionais”, — que, em cada Linux, convém omitir as partições que fazem parte dele, — pois já estão no respectivo “/etc/fstab”, e são montadas “naturalmente”, — para evitar acesso por caminhos (path) diferentes.

No Kubuntu, por exemplo, é desnecessário comandar a montagem de Linux1 e Home1, — acabaria acessando, ora como “/home”, ora como “/media/flavio/Home1”, — 2 coisas bem distintas, pois a segunda pode incluir as pastas de vários usuários.

No caso do Linux Mint, a montagem de Linux2 e Home2 já ocorre “naturalmente”. — E assim por diante.

As demais partições, precisavam ter a montagem automática habilitada em cada Linux:

  • Menu → Configurações do sistema → Hardware → Armazenamento removível

Partições dos HDDs internos, — sempre plugadas, — a serem montadas automaticamente no início de cada sessão

Já estava marcada a opção “Habilitar a montagem automática de mídia removível”, — denominação um tanto equívoca, pois abrange os “discos fixos”.

Estando marcada essa primeira opção, — no alto, — as 3 sub-opções tornam-se “marcáveis / desmarcáveis”.

Também já tinha sido desmarcada a 2ª sub-opção, — “Montar todas as mídias removíveis no início da sessão”, — pois várias dessas partições não serão acessadas com frequência.

Partições de dispositivos externos, — podem ser montados automaticamente ao conectar

Entre os dispositivos “desconectados”, interessava montar automaticamente a partição ”Backup2”, — a qualquer momento em que o “disco” SSD externo seja plugado.

Marcando a opção da segunda coluna, basta plugar para ser montada, — sem precisar clicar nela, como aconteceria se marcasse (só) na primeira coluna.

Conky


Ajustando as configurações “/home/.conkyrc” à reorganização das partições

Com essas alterações, era preciso ajustar as configurações do Conky, no arquivo (oculto) “/home/conkyrc”, para exibir a ocupação das partições que importa monitorar:

  • Acrescentar a nova partição Backup1
  • Substituir a antiga label “Terabyte” por Backup2
  • Acrescentar a partição Linux16
  • Eliminar as partições Linux5, Linux6 e Linux7, que agora ficam sem uso

Dolphin


Ocultar partições específicas no Dolphin, — ou “Mostrar todas”, para encontrar partições ocultadas

Essas mudanças e novidades nas partições fizeram com que o Dolphin e o Konqueror acabassem perdendo a noção dos “Locais” que devem ser exibidos ou ocultados.

Para ocultar uma “Entrada” em “Locais”, basta clicar com o botão direito e marcar a opção “Ocultar”.

Para encontrar partições ocultadas, basta clicar com o botão direito em qualquer lugar do painel “Locais”  (F9) e selecionar “Mostrar todas”, — as ocultadas aparecerão esmaecidas (cinza).

Dolphin com apenas 8 partições no painel lateral “Locais”, — além da Home, Raiz e Lixeira

Com essas e outras configurações, o Dolphin tem-se mostrado uma boa ferramenta de trabalho, — sem excesso de coisas não-utilizadas, — porém fáceis de encontrar, caso necessárias.

“Menu → Desligar / Sessão → Salvar sessão”, no KDE

Infelizmente, esqueci de “Salvar sessão”, — recurso habilitado pela opção “Restaurar sessão salva manualmente”, em “Configurações do sistema (KDE) → Iniciação e desligamento → Sessão do desktop”, — e no outro dia foi necessário fazer tudo isso, outra vez.

Normalmente, faço isso depois de fechar todos os aplicativos, — exceto KSysguard, Psensor, Xsensors, — e minimizar o Dolphin, com as abas nas pastas escolhidas para o trabalho dos próximos dias.

Resumo do particionamento


Partições dos sistemas, de dados, de backup e de swap

Em forma de Tabela, o particionamento é muito mais simples do que a descrição, passo-a-passo, das modificações requeridas pela inclusão do terceiro HDD.

No entanto, convém registrar as “receitas”, — pois o ciclo de 2 anos, às vezes faz com que esqueça como havia configurado um antigo Kubuntu LTS, na hora de configurar o LTS seguinte, — sem falar das novidades estranhas que surgem, e algumas coisas boas que desaparecem.

Lembrando que a reserva de espaços para instalar 6 Linux no novo HDD não significa que todos os 4 Linux já existentes tenham de ser, necessariamente, transferidos para ele.

Comparativo das funcionalidades já obtidas dos vários Linux instalados e testados em trabalho diário

Na verdade, faz muito mais sentido separar, — em 2 HDDs diferentes, — o Kubuntu 16.04 LTS e o Linux Mint 18 KDE (com as respectivas “/home”).

São os 2 sistemas “principais”, — desempenham tarefas que ainda não consigo realizar nos outros 3 sistemas, — e em caso de falha em um HDD, pelo menos 1 sistema “principal” continuaria pronto para uso imediato, em outro HDD.

Se encontrar um terceiro sistema Linux capaz de desempenhar todas essas tarefas, seria interessante instalá-lo em um outro dos 3 HDDs.

O fato de agora dispor de espaços para 4 + 6 + 3 Linux (contando com o SSD externo) também não significa que valha a pena instalar uma dúzia de sistemas. — Instalar só faz sentido (dentro da minha concepção particular), na medida em que possa configurar por completo, manter sempre atualizado, usar, observar e documentar, — coisas razoáveis até 2 ou 3 sistemas, no máximo, sob pena de acabar tomando várias horas por dia.

Melhor do que ter vários Linux, é ter espaço para instalar, — “se” (e quando) deparar algo que valha a pena conhecer. — E só é possível saber isso, com algum espaço livre para instalar e testar no uso do dia-a-dia.

É claro que interessa acompanhar o KDE “rolling release” do KDE Neon, bem como as novidades em construção no Debian testing, e a evolução do Kubuntu entre o atual LTS e o próximo, — e agora não será necessário removê-los, para testar algum outro.

Enfim, os espaços reservados devem facilitar o remanejamento dos sistemas, de uma partição para outra, entre os HDDs.

(*) Convenções


HDD → “Hard disk drive” → “disco rígido” (mecânico)
SSD → “Solid state drive” → “disco” de Memória em “estado sólido” (não-mecânico)

Sequência da reorganização



__________
Relato desenvolvido de 21 a 23 Dez. 2016, principalmente no Linux Mint 18 KDE e no Kubuntu 16.04 LTS.

— … ≠ • ≠ … —

Ferramentas &tc.


Postado por Mboaba às quinta-feira, dezembro 22, 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)