Translate

terça-feira, 27 de dezembro de 2016

Backup total e limpeza das partições de trabalho

Gráficos e tabelas do espaço aberto nas partições de trabalho nos discos rígidos, após a reorganização dos backups
Espaço aberto nas partições de trabalho, após a última etapa da reorganização dos backups

A reorganização dos backups decorreu da incorporação de um “disco” SSD externo de 1 Terabyte, seguida da instalação de um HDD interno de 1 Terabyte.

Em resumo, foi criada uma partição Backup1 (ext4) no novo HDD interno, — e uma partição “espelho” Backup2 (exFAT) no SSD externo, — o que permitiu retirar das partições de trabalho vários tipos de “backups parciais” (pastas de trabalho selecionadas) e vários “backups estáticos” (acervos a preservar inalterados).

Sequência da reorganização



Particionamento geral, — destacando as partições de dados e de backup

A reorganização dos backups e a “limpeza” das partições de trabalho foi concluída nos dias 24 e 25 Dez. 2016, — com salto de obstáculos, pelo fato de a partição “Backup1” (ainda) pertencer ao Administrador (root).

Em retrospecto, isso teve suas vantagens, — obrigou a mover algumas pastas pelo Konqueror (em modo root), — que apresenta um diálogo claro do número de arquivos, subpastas e Gibibytes, facilmente capturado com a tela.

Caso contrário, essas movimentações seriam feitas pelo Dolphin (modo usuário), — que não informa nada na tela, do início ao fim do processo, — exceto o nome do último arquivo, no final.

Só após a reorganização geral, foram explorados, — com calma, — os comandos “chown” e “chmod”, e transferida a “propriedade” da partição “Backup1” para o usuário.

Backups estáticos


Partição ext4 de 751,5 GiB, vazia, com 701,0 GiB livres

24 Dez. 2016 - Ao iniciar o trabalho, a nova partição “Backup1” (ext4, 751,5 GiB, HDD interno) encontrava-se ainda vazia, — exceto pela pasta de sistema “lost+found”, — e segundo o Dolphin, tinha 701,0 GiB livres.

Os 50,5 GiB não-“livres” representam 6,72% do tamanho nominal da partição.

Pasta “lost+found” vazia, até hoje, com tamanho “próprio” de 16,0 KiB

Passados vários dias, a pasta “lost+found”, — aberta no Konqueror em “modo root”, — apresenta-se sempre “vazia”, com 0 Byte, embora com tamanho “próprio” de 16,0 KiB.

Na linguagem do Konqueror, — “0 de 0, 0 B (0) de 0 B (0)”.

Início da cópia dos acervos de Backup2 para Backup1, pelo Krusader em modo root

Constatado que a nova partição “Backup1” (ext4, HDD interno) pertencia ao Administrador ou “Super Usuário” (root), foi utilizado o Krusader em “modo root” para copiar lá 4 pastas de “backup estático” (acervos a preservar inalterados) que já estavam no espelho Backup2 (exFAT, SSD externo).

Esse material seria eliminado das partições de trabalho “E:\” e “F:\” (onde ocupava espaço, por falta de alternativa), tão logo tivesse outra cópia em HDD, — para não confiar unicamente no SDD.

Terminada a cópia de 217 mil arquivos, após 2h37min

Esse conjunto de 4 pastas, — com 6.957 subpastas e 99,6 GiB, — foi copiado da partição exFAT do SSD externo para a partição ext4 do HDD interno, em 2 horas 37 minutos.

Ao final, o Dolphin indicava 601,9 GiB livres, — redução de apenas 99,1 GiB em relação à cifra inicial.

Ao que parece, o espaço “não-livre” cedeu 0,5 GiB para a guarda dos 99,6 GiB copiados.

Backup total de “E:\” e “F:\”


Deletando as tarefas do antigo backup parcial (pastas avulsas), no perfil Default

Para substituir o “backup parcial”, — pastas escolhidas de “E:\” e “F:\” que eram duplicadas na partição “Home1”, — foram deletadas do perfil “Default” do luckyBackup todas as antigas “tarefas”, que deixarão de ter utilidade.

Novas tarefas do luckyBackup, — copiar partições inteiras

Em seu lugar, foram criadas apenas 2 tarefas, — copiar as partições “E:\” e “F:\” (inteiras), para a partição Backup1 do novo HDD externo.

Início do backup completo das partições “E:\” e “F:\” para o novo HDD

O novo “backup total” foi iniciado às 15:41.

Um triângulo de alerta indica que as 2 novas tarefas não tinham data da última vez em que foram realizadas, — normal.

Backup entre HDDs internos SATA, concluído em 1 hora e 11 minutos

Embora envolvendo a transferência de 188 GiB, — quase o dobro da cópia realizada antes pelo Krusader, — o fato de ocorrer entre HDDs internos SATA (dois de 320 GB e um de 1 TB) fez com que transcorresse cerca de 4 vezes mais rápido, em 1 hora 11 minutos.

Correção do destino


Cometendo velhos erros, — pasta dentro de pasta, no destino do backup

Bastou examinar o resultado no Dolphin, para ver que havia repetido um velho erro do antigo backup parcial, — criar pastas separadas, no destino, em cada uma das quais, o luckyBackup criou uma subpasta, — quando o mais simples era deixar o próprio luckyBackup criar todas as subpastas em uma pasta só.

Pastas de destino movidas em 1 nível

Dessa vez, porém, foi adotada a solução mais simples e rápida, — mover as subpastas “/E” e “/F” para fora (e ao lado) de “part_E” e “part_F”, usando o Konqueror em modo root.

Essa operação não envolve movimentação “física” dos arquivos, — apenas altera seu caminho (path), dentro da “árvore”. — Tal como alterar o nome de uma pasta, e num piscar de olhos se altera o “path” de todo seu conteúdo.

É mais demorado dizer, do que fazer. — Depois disso, bastava deletar “part_E” e “part_F”, que ficaram vazias.

Sincronização rápida do luckyBackup, — transferindo apenas as novas capturas de tela

Corrigido o “path” nas tarefas, o luckyBackup aceitou os arquivos que encontrou no novo “local” de destino, — limitou-se a transferir as capturas de tela mais recentes, — e concluiu a sincronização em 2 minutos 13 segundos.

Eliminando pastas duplicadas


Cinco acervos duplicados em Backup1, — provenientes de “E:\” e de Backup2

Várias pastas de “backup estático” (acervos a preservar) estavam espalhadas pelas partições “E:\” e “F:\”, nos últimos anos, — e continuaram lá, mesmo depois de copiadas (algumas) para a partição Backup2, no SSD externo. — A ideia era manter pelo menos uma cópia em HDD interno, por segurança.

Com o backup completo, — tanto do Backup2 (SSD externo), quanto das partições “E:\” e “F:\”, — alguns acervos passaram a ter mais de 2 cópias.

Sincronização de pastas duplicadas, no Konqueror, para certificar que são absolutamente iguais

Em tese, bastava deletar as duplicatas desnecessárias, — mas era bom ter certeza de (ainda) serem absolutamente iguais.

Para não confiar na memória (achômetro), — em meio a várias reorganizações menores, nos últimos meses, — os pares de duplicatas foram sincronizados no Konqueror.

Tarefas de sincronização das 2 partições Backup1 e Backup2

Por fim, foi criado um segundo “perfil ” do luckyBackup, — com a opção de “destino FAT / NTFS”, — para sincronizar a partição Backup1 (ext4, HDD interno) na partição Backup2 (exFAT, SSD externo).

Parte dos ajustes feitos antes em Backup1, — renomear, mover, excluir pastas, — já tinham sido aplicados também em Backup2, para tornar menos demorada a primeira sincronização.

Partições de trabalho


Movendo acervos de preservação inalterada para Backup1 (e 2)

25 Dez. 2016 - A essa altura, já podia ser excluído um grande volume de arquivos das partições de trabalho:

  • Home1 - deletado o antigo backup parcial
  • Home2 - deletados vários acervos, agora em Backup1 / Backup2
  • E:\ - deletados vários acervos, agora em Backup1 / Backup2
  • F:\ - movidos vários outros acervos para Backup1 / Backup2

Exemplo de acervo a manter inalterado é a antiga pasta “Digital-Sony”, — com todas as fotos (e alguns vídeos) feitas desde 2003, — cujo conteúdo não pode se recuperado de nenhuma outra fonte, — exceto um punhado de velhos CDs / DVDs, de cuja durabilidade é difícil ter certeza.

As imagens originais (e seus dados Exif) não devem ser alterados, — para editar alguma foto, basta uma cópia nas pastas de trabalho.

Como parte da reorganização, a pasta foi renomeada “001_Fotos-digitais” (pois agora inclui imagens do celular), — as antigas pastas “mensais” foram reagrupadas em “anuais”, — e apenas as de 2016 foram mantidas na partição de trabalho.

Com essas e outras reorganizações, Home1, Home2 e “E:\” tornaram-se partições quase vazias, — e as 2 primeiras foram incluídas no backup dinâmico, pelo luckyBackup, — pois agora podem ser usadas como partições de trabalho.

CDs de instalação


Usando K3b para fazer backup (ISO) de CD / DVD de instalação de placas e aplicativos

Uma providência que já estava passando da hora, era fazer backup de antigos CDs de instalação de placas, periféricos e aplicativos, — pela gravação de suas imagens ISO na pasta Downloads1 (na Home1).

Formatos & permissões


Permissão geral de leitura, em alguns arquivos do Backup1 (ext4)

28 Dez. 2016 - Terminado o principal da reorganização geral dos espaços de trabalho e dos backups, a verificação dos resultados, — com as correções necessárias, — acabou impondo 2 ou 3 questões, que vinha evitando há cerca de 10 anos.

  • Partições “adicionais” ext4
  • Permissões, chmod, chown etc.

Por partições “adicionais”, leia-se, — partições que “não fazem parte” de nenhum sistema, — que não são “raiz” (“/”), nem “/home” de nenhum Linux. — Existem à parte, para leitura e gravação pelo Kubuntu, pelo Mint, pelo Debian, pelo KDE Neon, — ou qualquer outro, que venha a ser instalado em paralelo (dualboot).

As partições “E:\” e “F:\” nunca criaram problemas de “permissão” para renomear, gravar, deletar, — e isto foi um dos motivos para adotar o formato exFAT na partição “Backup2” do SSD externo.

  • Uma hipótese que parece explicar essa moleza toda: — “permissions are set at the time of mounting the partition with umask, dmask, and fmask and can not be changed with commands such as chown or chmod”. — Ou seja, partição FAT / exFAT é de quem “montar”.

Permissões restritivas, em alguns arquivos do Backup1 (ext4), — usuário não pode nem visualizar

Mas, na partição “Backup1” do HDD interno, finalmente foi adotado o formato ext4, — e voltaram os obstáculos que complicavam a vida do iniciante, 10 anos atrás. — Felizmente, agora com um pouco mais de noção do Linux.

A partição “Backup1” já nasceu pertencendo ao “Super Usuário” (Root), — o que não foi problema nenhum para o luckyBackup, rodando como “root”, — nem para o Krusader, também usado como “root” para criar as pastas iniciais, e colocar lá os backups “estáticos”, que não precisarão ser sincronizados (armazenamento de acervos).

Problema, foi quando muitas imagens não puderam ser, sequer, examinadas pelo “usuário comum”, via Dolphin, Gwenview etc.

Transferindo a “propriedade” da partição Backup1 para o usuário

29 Dez. 2016 - Depois de alguns comandos ignorantes, — tipo, “chmod -R 777” (que escancara as porteiras), “chmod -R 644” (que libera escrita mas impede de abrir a partição), — os neurônios chegaram à solução mais simples de todas:

sudo chown -R flavio Backup1

Transferir a “propriedade” da partição Backup1 para o “usuário”, — era o quanto bastava, para resolver todos os problemas, de uma vez por todas. — A partir daí, o “usuário” pode examinar qualquer arquivo, fazer buscas por conteúdo, ou o que bem entender.

Parte dessa simplicidade é devida ao uso do Dolphin, com “Exibir → Painéis → Terminal” (F4). — Aberto na pasta correta (“/media/flavio”), dispensa lembrar e digitar essa parte dentro do comando, e mostra o resultado na hora, — senão, atualize com F5.

Como a experiência posterior mostrou que, agora, todos os Linux conseguem lidar com essa partição “adicional” em ext4, fica aberto o caminho para migrar também as partições “E:\” e “F:\” para esse formato, — e matar a curiosidade sobre o espaço ocupado pelos arquivos, o espaço “livre” e o espaço “desperdiçado”, após a mudança.

Alterando as permissões, para que apenas o “proprietário” possa entrar, ver, escrever em Backup1

Depois disso, era até bobagem perder tempo com “chmod”. — Mas, quando a brincadeira dá certo, ninguém quer parar, — e foi aplicado um comando para restringir as permissões em todas as pastas, subpastas e arquivos da partição Backup1.

Não, que isso pareça aumentar uma suposta “segurança”, — essa preocupação é muito relativa, para um computador doméstico, sem rede, sem nada, — e as coisas também não são tão simples.

Primeiro, foi constatado que outra conta não tem acesso à pasta “/media/flavio”, — opção de ponto de montagem escolhida tendo isso em vista.

Segundo que, — no caso da partição Backup1, — os efeitos desse “chmod 700” são mais perecíveis do que alface. Bastam 2 minutos e 25 segundos, para o luckyBackup restabelecer as permissões de 11.846 subpastas e 224.710 arquivos, conforme os originais em “E:\”, “F:\”, “Home1” e “Home2”. — Se quiser alterar as permissões em definitivo, é preciso alterá-las nestas partições.

Terceiro, que ainda não foi encontrado “chmod” capaz de negar permissão para o “grupo” encostar um caminhão e levar a casa inteira, — backup incluído.

Sequência da reorganização



Formação sócio-econômica das partições e sua ocupação


Evolução do espaço disponível e ocupação das partições, nos últimos 8 meses

Criadas como verdadeiros latifúndios sem uso, — ao definir o particionamento geral dos 2 discos rígidos (HDDs) de 320 GB, em 2009, — 6 anos depois, as partições de trabalho “E:\” (70 GiB) e “F:\” (180 GiB), já davam sinais de esgotamento.

Àquela altura, já mal lembrava a folga dos primeiros anos, — quando dezenas de velhos backups em CD / DVD (numerados de 1 a 130-e-tantos) tinham sido, simplesmente, copiados de volta para a partição de trabalho (“F:\”) no disco rígido.

Aqueles velhos backups em CD / DVD tinham o péssimo hábito de incluir “n” duplicações, de dezenas de milhares de arquivos, — em alguns casos, todos os arquivos dos antigos HDDs, em várias datas diferentes; outras vezes, apenas os arquivos modificados desde o backup anterior, — além de muito lixo, de épocas em que salvava inúmeras páginas web, cada uma com milhares de penduricalhos inúteis (hábito substituído por PDF + TXT com texto, data e link).

Deletar em massa os repetecos inúteis, — mas, preservando sucessivas versões dos arquivos alterados, cuja consulta às vezes é necessária, — era tarefa insana, para ser feita de uma só vez. Quase impraticável, como trabalho com começo, meio e fim.

Busca em arquivos.TXT com listagens do conteúdo de antigos CD / DVD de backup

Porém, mantidos durante alguns anos na partição de trabalho (“F:\”), bastou ir arrastando as pastas realmente necessárias, para dentro da nova “árvore” de arquivos de trabalho, — e aproveitando para deletar o que era claramente inútil, — até que um dia, anos depois, o restante dos antigos backups trazidos de volta para o HDD já podia ser deletado.

Localização de arquivos por pasta em velhíssimos CDs / DVDs de backup

Às vezes, ainda faltava alguma coisa, mas bastava um “CTRL-F” por conteúdo, — na pasta com as listagens em TXT, — para localizar determinado CD / DVD, e copiar de volta mais algumas pastas, diretamente para a nova “árvore” de arquivos de trabalho.

Desse modo, a partição “F:\” acabou por se tornar uma “árvore” de pastas com (quase) todos os arquivos relevantes, guardados em backup desde a década de 1990, — inicialmente em disketes de 5¼’’, de 3½’’, depois em discos Zip, tudo em CD / DVD desde 2003, — e tudo (que de fato interessa) em HDD, de 2009 em diante.

Por volta de 2015, enfim, era cada vez mais raro, ainda precisar recuperar alguma coisa dos antigos backups em CD / DVD, — mas também acabaram as cópias em HDD que ainda pudesse deletar, para continuar abrindo espaço. — Em economês, “a oferta de espaço tornou-se inelástica, perante uma demanda invariavelmente crescente”.

Claro está que, àquela altura, o hábito de fazer backups em DVD já estava banido, de longa data, — substituído por backup das pastas de trabalho na partição “/home” do Linux1 (“Home1”), via luckyBackup ou Unison, — porém, novos CDs e DVDs, com material precioso, continuaram sendo recebidos dos colaboradores.

Nestes casos, o conteúdo era copiado para a partição de trabalho “E:\” (onde as cópias periódicas dos sites e blogs, zipadas, ocupam pouco espaço). O material dos colaboradores era trazido para HDD, como “backup estático”, contra eventual perda ou dano dos CDs e DVDs recebidos (e também contra falhas que, cedo ou tarde, afetam sucessivos leitores de CD-DVD, nos momentos mais inconvenientes).

Aliás, faz cada vez menos sentido, colocar mídia na bandeja, montar, examinar, ejetar, guardar etc., — é muito mais prático manter em HDD o material recebido. — No entanto, para trabalhar, é mais seguro copiar (apenas o que será usado), para uma pasta sobre aquele assunto, na “árvore” de arquivos de trabalho (“F:\”), onde documentos podem ser agrupados, editados etc., sem alterar os originais.

Desse modo, a partição “E:\” tornou-se um “armazém” de originais, — com backup na partição “/home” do Linux2 (“Home2”).

Só que, na prática, a teoria acabou sendo outra.

Conversão de arquivos TIFF em JPEG


Conversão em massa de arquivos TIFF em JPEG, em Setembro de 2015

No 2º semestre de 2015, um amigo vandalizou, — mandando um SSD portátil, com nada menos que 121.029.086.374 bytes (112,7 GiB) em imagens, planilhas e PDFs da maior preciosidade, para copiar.

Não havia espaço para isso, — mesmo deletando duplicatas (backups estáticos), além de 6.942 arquivos TIFF (após convertê-los em JPEG). — Foi necessário escolher apenas 28,8 GiB, para guardar (com cópia, excepcionalmente, em meia-dúzia de DVDs), antes de devolver o SSD portátil.

Como subproduto, várias coisas foram deslocadas, — do lugar “planejado”, para algum outro local “provisório”. — Em português claro, bagunçou-se o coreto.

É desnecessário dizer que, — desde aquela época, — espaço em disco rígido tornou-se assunto de sobrevivência. Uma carteira recheada resolveria isso num piscar de olhos, mas não era o caso, na época.

Infelizmente, em meados de 2015, ainda não tinha Conky na tela, — nem o hábito de fazer PrintScreen, para documentar (instantaneamente) a ocupação das partições, o movimento de pastas etc. — Os dados anotados fornecem poucos detalhes:

14 Set. 2015 - mogrify TIFF → JPEG em massa (diário geral). Havia 6.942 TIFF. — Em parte, haviam sido extraídos de arquivos PDF em vários formatos (para conferir), por isso, já havia JPEG duplicado, e nesses casos, bastou deletar os arquivos TIFF.

15 Set. 2015 - Examinando os JPEG gerados em massa, antes de destruir os velhos TIFF.

    6.915 TIFF
    Usados em F:\  → 163 GB
    Livre em F:\   →  16 GB
 
    23:23
 
    Usados em F:\  → 143   GB
    Livre em F:\   →  36,8 GB

Donde se supõe que foram liberados mais de 20 GB (18,6 GiB), pela conversão em massa de TIFF em JPEG, — mas não há como saber quanto espaço foi aberto, com outras providências, antes ou depois desse dia.

Conversão e eliminação do Photoshop


Automatização de tarefas em lote, no Photoshop, — converter em JPEG e fechar

Meses depois, novas providências se tornaram urgentes, para abrir mais algum espaço nas partições de trabalho.

4 Mai. 2016 - Começou a ser esvaziada a antiga partição “C:\”, — pela desinstalação de programas do Windows, seguida da limpeza de várias pastas sobreviventes, — com a simultânea eliminação de 7.048 arquivos Photoshop (“.psd”) existentes na partição “F:\”.

Converter em JPEG todos os arquivos Photoshop em uma pasta e todas as subpastas

Nos casos em que os arquivos “.psd” representavam a única cópia (originais de scanner), foi utilizada sua própria ferramenta de automação, — abrir todos os arquivos de uma pasta, “salvar como” JPEG, fechar, — após eliminar as respectivas duplicatas com “camada” (layer), que interromperiam o processo, solicitando intervenção manual.

Comparação com arquivos JPEG, — e excluir arquivos do Photoshop

8 Mai., às 7:02 - Quando restavam pouco mais de 119 arquivos do Photoshop (322,0 MiB), o Conky indicava a seguinte ocupação das partições:

    Home2    49,4 /  73,5 GiB
    Home1   150   / 176   GiB
    F       125   / 180   GiB - 54,6 GiB livres, cf. Dolphin
    E        50,0 /  70,0 GiB

A diferença entre a pasta de trabalho “F:\” e seu backup (“Home1”) é uma indicação aproximada do espaço aberto até aquele momento.

Ainda havia 6.513 arquivos Photoshop na “Home1”, totalizando 18,1 GiB, — e apenas 17,3 GiB livres, segundo o rodapé inferior do Dolphin.

18:11 - Após rodar o backup parcial, — só as pastas de trabalho, — pelo luckyBackup, a ocupação das partições ficou assim:

    Home2    52,2 /  73,5
    Home1   126   / 176    - Dolphin: 40,5 GiB free às 18:19
    F       125   / 180
    E        50,0 /  70,0

De passagem, isso indica que mais alguma coisa foi “armazenada” (backup estático) na “Home2”, — mas não em “E:\” (a menos que também já estivesse lá), — com cerca de 2,8 GiB.

“Disco” SSD externo de 1 TB


Árvore de diretórios originalmente existentes no SSD externo de 1 Terabyte

4 Jul. 2016 - A chegada de um SSD externo de 1 Terabyte (931,5 GiB), presenteado por um amigo, com 743,4 GiB livres, — e o conselho de deletar tudo que não apresentasse interesse, — alterou (para menor) o projeto de expansão do espaço de trabalho.

Ao invés de adquirir 2 HDDs de 1 Terabyte, agora bastaria adquirir 1 HDD de 1 Terabyte.

Como não ficou documentado o tamanho total dos arquivos recebidos com o SSD externo, — só uma listagem de todos os arquivos, e uma “árvore” de todas as pastas, em TXT, — resta a conta de subtração, que dá 188,1 GiB, — incluída alguma “perda” de espaço (NTFS) em blocos parcialmente ocupados, além da Lixeira ($RECYCLE.BIN), onde havia 6.673 pastas (6,5 GiB).

O registro da época, aqui no Byteria, indica que foram eliminados cerca de 140 GiB em arquivos + Lixeira, até o dia 6.

6 Jul. 2016 - Esvaziada a Lixeira e eliminadas milhares de subpastas em “Programas” e “Oldies”, — aplicativos e utilitários MS-DOS e Windows, desde a década de 1980, — o Dolphin indicava ocupação de 49,4 GiB e espaço livre de 880 GiB (“perda” de apenas 1,3 GiB, em NTFS).

Este foi, provavelmente, o menor índice de ocupação do SSD externo de 1 Terabyte, — que, pouco depois, recebeu o backup estático (armazenamento) de vários acervos, que até então tinham 1 única cópia em HDD, — passando, então, a 93,5 GiB ocupados.

Reparticionamento do SSD externo


Redimensionamento da partição (única) original, abrindo espaço para outras partições

25 Out. 2016 - O re-particionamento do SSD externo de 1 Terabyte serviu de ensaio para testar os planos de particionamento do futuro HDD interno de 1 Terabyte, — porém apresentou algumas características únicas, — por ter de ser feito sem perda dos arquivos já existentes.

A partição (única) NTFS, que já havia recebido mais alguma coisa (estava com 98,8 GiB), foi “encolhida” para cerca de 117 GiB.

No espaço liberado, foi criada uma partição estendida, de 814 GiB, — e dentro dela, uma partição lógica para backup, — em formato exFAT, tamanho 795 GiB, label “Terabyte” (atual “Backup2”).

Copiando 98,8 GiB entre 2 partições do SSD externo, em 3h20min

Em seguida, os 98,8 GiB de arquivos existentes na partição original (“encolhida”) foram copiados para a nova partição de backup.

Com isso, a partição original (encolhida) pôde ser deletada, — e criadas 3 partições primárias ext4 no espaço liberado.

Kubuntu 17.04 no SSD externo


Com a instalação do Kubuntu 17.04, a ocupação da partição de backup externo passou a ficar registrada

28 Out. 2016 - Após instalar o Kubuntu 17.04 Zesty Zapus no SSD externo, a partição de backup (795 GiB), — ainda com uma label provisória “Terabyte”, — finalmente foi incluída no Conky, e daí por diante sua ocupação passou a ser registrada em inúmeras capturas de tela.

Ensaio de backup total


Backup total da partição “F:\”

30 Nov. 2016 - Ensaio de backup total, avaliação do Unison x luckyBackup, e procedimentos a serem adotados quando fosse instalado um novo HDD interno de 1 Terabyte.

O “backup total”, — de todas as pastas em “E:\” e “F:\” (e não só das “pastas de trabalho”), — elevou essa ocupação da partição “Backup2” (então chamada “Terabyte”) de 116 para 319 GiB, em 2 etapas.

Também aqui, o ensaio com uma partição “Backup2” (então “Terabyte”), — em formato exFAT, — apresentou algumas características únicas.

Deixou de prever, por exemplo, o que ocorreria mais tarde, com as “permissões” dos arquivos, na partição “Backup1”, em formato ext4.

HDD 1TB e reorganização


20 Dez. 2016 - Instalado o novo HDD interno de 1 Terabyte.

24 Dez. 2016 - Reorganização completa dos backups, — “dinâmico” (com luckyBackup) e “estático” (acervos), — na partição “Backup1” (HDD interno), — espelhada em “Backup2” (SSD externo).

25 Dez. 2016 - Excluídos os antigos backups parciais em “Home1”, — e também os acervos que estavam espalhados em “E:\”, em “F:\”, e em “Home2”. — Agora, acervos e “backup total” ficam em “Backup1”, com cópia regular em “Backup2”.

Com isso, as partições “E:\”, “F:\”, e “Home2” voltam a ter espaço mais do que suficiente para trabalhar mais alguns anos, sem aperto algum, — falta esvaziar mais a partição “Home1”, — e começa a tarefa de repensar o melhor uso desses espaços liberados.

Sequência da reorganização



_________
Levantamento e relato produzidos de 27 a 30 Dez. 2016, principalmente no Kubuntu 16.04, — para evitar que o luckyBackup seja disparado a partir de mais de 1 dos sistemas Linux instalados.

— … ≠ • ≠ … —

Ferramentas &tc.


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

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: , , , , , , , , , , , , , ,
Assinar: Postagens (Atom)