Como restaurar um arquivo com hardlink

2

Eu tenho um sistema de arquivos com uma série de backups arquivados em data de outro sistema de arquivos. O backup usa hardlinks para copiar apenas o delta entre instâncias de arquivamento consecutivas. A unidade teve alguns dados corrompidos e eu estou trabalhando para substituí-lo, no entanto, alguns arquivos estão corrompidos e não copiados com sucesso. Eu tenho outras cópias dos arquivos danificados para restaurar, mas eu não sei uma boa maneira de substituir o arquivo danificado dentro da estrutura de hardlinks.

01/01       02/01       03/01        
 -file1  >>  -file1  x               Added in 01/01, deleted by 03/01
 -file2  >>  -file2  >>  -file2      Added in 01/01, never deleted
             -file3  >>  -file3      Added in 02/01, never deleted

No caso acima, há um armazenamento de dados para file2 , com dois (ou três dependendo de como você conta) hardlinks. Se os dados do arquivo base estiverem corrompidos, como posso usar meu arquivo de backup para restaurar file2 e reter seus links de hardware?

Mais informações:

  1. Os dados originais residem em um dispositivo físico em uma estrutura de pastas.
  2. As cópias de backup / arquivamento são da estrutura de pastas completa contida no dispositivo de dados original (1.). Eles são consecutivos no tempo, desduplicados e vinculados entre si no dispositivo de backup.
  3. A cópia a ser restaurada é um terceiro dispositivo usado para armazenar imagens do dispositivo de backup para armazenamento a longo prazo.
  4. Os erros ocorreram no dispositivo de backup listado em (2.). Eu gostaria de ter os arquivos corrompidos neste dispositivo de backup restaurado a partir do local original (1.) ou do dispositivo de armazenamento frio (3.), dentro da estrutura dos backups / archive.
  5. A lógica de backup:

    5.1. Encontre a última data / hora marcada na pasta de backup <last backup folder> on device (2.)

    5.2. Crie uma nova pasta de backup vazia <new folder> com o carimbo de data / hora atual.

    5.3. Faça uma cópia com hardlink dos arquivos na última pasta de backup:

    cp -al <last backup folder> <new folder>
    

    5.4. Faça cópia dos dados de <source data> de (1.) para a nova pasta de backup, sobre a pasta de backup com link físico feita em (5.3.):

    rsync -azH --delete <source data> <new folder>
    

Atualização: 14/03/2017

Tendo tentado usar o conselho de uma resposta, o arquivo corrompido no destino não pode ser substituído. Claramente, o destino naquele local tem uma falha grave de algum tipo e os dados de substituição precisam ir para um novo local físico no disco.

    
por J Collins 07.03.2017 / 11:11

1 resposta

2

Use rsync -azH --inplace

Há vários avisos sobre essa opção na página do manual:

--inplace

This option changes how rsync transfers a file when the file's data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file. This has several effects:

(1) in-use binaries cannot be updated (either the OS will prevent this from happening, or binaries that attempt to swap-in their data will misbehave or crash),

(2) the file's data will be in an inconsistent state during the transfer,

(3) a file's data may be left in an inconsistent state after the transfer if the transfer is interrupted or if an update fails,

(4) a file that does not have write permissions can not be updated, and

(5) the efficiency of rsync's delta-transfer algorithm may be reduced if some data in the destination file is overwritten before it can be copied to a position later in the file (one exception to this is if you combine this option with --backup, since rsync is smart enough to use the backup file as the basis file for the transfer).

WARNING: you should not use this option to update files that are being accessed by others, so be careful when choosing to use this for a copy. This option is useful for transfer of large files with block-based changes or appended data, and also on systems that are disk bound, not network bound.

The option implies --partial (since an interrupted transfer does not delete the file), but conflicts with --partial-dir and --delay-updates. Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest and --link-dest.

    
por 08.03.2017 / 18:35