Instantâneo `cp -al` cujos links físicos são direcionados para um novo arquivo quando editado


11

Estou tentando tirar instantâneos de uma pasta enorme regularmente.

Eu li aqui: http://www.mikerubel.org/computers/rsync_snapshots/#Incremental
que cp -altira um instantâneo de uma pasta, simplesmente copiando os links físicos.

Tudo isso é ótimo, mas o problema é que, neste snapshot, se eu alterar um arquivo, ele muda em todos os snapshots. O que eu gostaria, em vez disso, é fazer com que o sistema crie um novo arquivo em mudança e vincule-o a ele. Dessa forma, cada instantâneo não se tornaria inválido em uma edição do primeiro arquivo.

Como posso conseguir isso?

ps eu tentei rsync -a --delete --link-dest=../backup.1 source_directory/ backup.0/, mas tem o mesmo problema.

Respostas:


7

É assim que os hardlinks funcionam. Mas, existem maneiras de contornar isso:

Algumas opções vêm à mente:

  • Use um sistema de arquivos com suporte para arquivos de cópia na gravação, como btrfs. Obviamente, se você estivesse usando o btrfs, usaria apenas os snapshots nativos ... Se o seu sistema de arquivos suportar, você poderá usá-lo cp --reflink=always. Infelizmente, o ext4 não suporta isso.
  • Compartilhe apenas hardlinks entre seus snapshots, não com o original. Ou seja, a primeira vez que você vir uma versão específica de um arquivo, copie-o para o instantâneo. Mas na próxima vez, vincule-o ao instantâneo anterior. (Não tenho certeza de qual programa eu costumava fazer isso - uma década atrás -, mas a pesquisa aparece em dirvish, obnam, storebackup e rsnapshot)
  • Dependendo de como seus arquivos estão sendo alterados, você poderá garantir que uma temp / renomeação de gravação seja usada para alterá-los, e isso interromperá o hardlink - para que a versão no instantâneo permaneça intocada. Isso é menos seguro, pois os erros podem corromper seu instantâneo.
  • Tire instantâneos LVM de todo o sistema de arquivos.

Obviamente, existe a outra opção - use um sistema de backup adequado. A maioria deles consegue fazer backup apenas dos arquivos alterados.


O que você recomenda como forma de fazer backup de uma pasta massiva?
Hermann Ingjaldsson 29/03

Eu estava pensando em usar o rsync em um servidor que possui um cronjob para executar o cp -al regularmente em snapshots .. juntamente com o rsync em diante para obter ainda mais cópias. Como isso soa?
Hermann Ingjaldsson 29/03

@HermannIngjaldsson bem, depende de como você faz seus backups. Pessoalmente, eu o adicionaria à minha configuração do Bacula - mas eu não recomendaria isso, a menos que você tenha várias máquinas para fazer backup ou já conheça o Bacula. Então, acho que sugiro que você tente o rsnapshot primeiro.
derobert 29/03

rsnapshoté bom
developerbmw

4

O que você está procurando é uma forma de cópia na gravação , em que vários arquivos com o mesmo conteúdo usam o mesmo espaço no disco até que um deles seja modificado. Os links físicos implementam apenas a cópia na gravação se o aplicativo que faz a gravação exclui o arquivo e cria um novo arquivo com o mesmo nome (o que geralmente é feito criando um novo arquivo com um nome diferente e movendo-o no lugar). O aplicativo que você está usando evidentemente não está fazendo isso: está substituindo o arquivo existente.

Alguns aplicativos podem ser configurados para usar a estratégia de substituição. Alguns aplicativos usam a estratégia de substituição por padrão, mas usam a estratégia de substituição quando veem um arquivo com vários links físicos, precisamente para não interromper os links físicos. Sua técnica atual de instantâneo funcionará se você puder configurar seu aplicativo para substituir em vez de substituir.

O Fl-cow modifica os programas para usar sistematicamente a estratégia de substituição em arquivos com vários links físicos.

Como alternativa, você pode armazenar seus arquivos em um sistema de arquivos que executa a cópia na gravação ou desduplicação, ou possui um recurso de captura instantânea, e não se preocupe com links físicos : Btrfs ou Zfs . Dependendo do seu esquema de particionamento, o uso de snapshots do LVM pode ser uma opção.

Minha recomendação é usar uma ferramenta de instantâneo adequada. Fazer backups confiáveis ​​é surpreendentemente difícil. Você provavelmente quer o rsnapshot .


2

O seguinte é um script ruby ​​que escrevi que envolve o "cp -al" e o rsync em um bom script que pode ser executado manualmente ou via cron. O destino pode ser local ou remoto (via ssh):

Timemachine do gueto

A resposta básica à sua pergunta, como mencionado em um comentário anterior, a fonte precisa ser mantida separada dos links físicos. Por exemplo, assuma um backup diário do seu diretório pessoal:

Fonte:

  • / home / flakrat

Destino:

  • / dados / backup / diariamente
    • /Segunda-feira
    • /terça
    • / quarta-feira
    • / quinta-feira
    • ...

Os links físicos são criados executando "cp -al" no backup de ontem. Diga que é terça-feira de manhã quando você o executa:

cd /data/backup/daily

rm -rf tuesday

cp -al monday tuesday

rsync -a --delete /home/flakrat /data/backup/daily/tuesday/


0

O rdiff-backup parece fazer o que você quer, dê uma olhada.

Usando o rsync, você deve primeiro fazer um backup completo sem usar links físicos. O próximo backup pode apontar para o backup anterior e o link físico para ele. Dessa forma, seus backups não são vinculados aos arquivos de trabalho (os que você está modificando). Exemplo. Se meu backup anterior fosse uma pasta backup.01, meu script de backup aumentaria primeiro as pastas renomeando-as em uma para que backup.01 se torne backup.02. Em seguida, o script cria uma nova pasta vazia chamada backup.01. em seguida, sincronizaria novamente o novo backup na nova pasta e vincularia o backup.02 a fim de que apenas novos arquivos ocupem espaço no backup. O comando rsync ficaria assim: rsync -rlt caminho de origem backuppath / backup.01 --link-dest = backuppath / backup.02

Como você pode ver, todo o vínculo físico está acontecendo no caminho do backup. Dessa forma, você não precisa se preocupar com a cópia na gravação ao modificar arquivos no caminho de origem.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.