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

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)