arquivos de backup para um servidor remoto com várias versões usando a opção de hardlink rsync

Question

Para usar a opção de link físico rsync para fazer backup de arquivos remotamente, de modo que o servidor de backup remoto possa manter várias versões dos backups, o diretório link-dest e o diretório de destino devem estar no mesmo disco remoto. Mas a opção 'rsync --link-dest' só usa um caminho local. Para executar um script do servidor no qual um diretório deve ser submetido a backup, ele precisa primeiro fazer o SSH para o servidor de backup e, a partir do servidor de backup, executar o comando rsync da seguinte forma:

ssh [email protected] 'rsync -a --delete --rsh "ssh -l root -i /root/.ssh/key2" --link-
dest=backupDict.1 19.2.2.1:/mnt/mountDict backupDict'

Existe uma maneira menos complicada de fazer backup de arquivos com link físico?

Também recebi logs de erro e congelamento do hipervisor durante o processamento de backup, ao fazer o snapshot de um vm e montar o snapshot lv como o diretório original. Snapshot e mount a vm são encontrados sem usar o método de link duro rsync. Existe uma maneira de consertar isso?

Mar 10 02:36:59 kvm kernel: BUG: Bad page map in process udevd  pte:800000081ad43645 pmd:409f37067
Mar 10 02:36:59 kvm kernel: addr:00006aff4f837000 vm_flags:00100173    anon_vma:ffff88081f7dc448 mapping:(null) index:7fffffff1
Mar 10 02:37:02 kvm kernel: Pid: 5091, comm: udevd Not tainted 2.6.32-        358.18.1.el6.x86_64 #1
Mar 10 02:37:03 kvm kernel: Call Trace:
Mar 10 02:37:03 kvm kernel: [<ffffffff8113ef18>] ? print_bad_pte+0x1d8/0x290
Mar 10 02:37:03 kvm kernel: [<ffffffff8111b970>] ? generic_file_aio_read+0x380/0x700
Mar 10 02:37:03 kvm kernel: [<ffffffff8113f03b>] ? vm_normal_page+0x6b/0x70
Mar 10 02:37:03 kvm kernel: [<ffffffff8114179f>] ? unmap_vmas+0x61f/0xc30
Mar 10 02:37:03 kvm kernel: [<ffffffff811476d7>] ? exit_mmap+0x87/0x170
Mar 10 02:37:03 kvm kernel: [<ffffffff8106b50c>] ? mmput+0x6c/0x120
Mar 10 02:37:03 kvm kernel: [<ffffffff811889a4>] ? flush_old_exec+0x484/0x690
Mar 10 02:37:03 kvm kernel: [<ffffffff811d9700>] ? load_elf_binary+0x350/0x1ab0
Mar 10 02:37:03 kvm kernel: [<ffffffff8113f3ff>] ? follow_page+0x31f/0x470
Mar 10 02:37:03 kvm kernel: [<ffffffff811446e0>] ? __get_user_pages+0x110/0x430
Mar 10 02:37:03 kvm kernel: [<ffffffff811d7abe>] ? load_misc_binary+0x9e/0x3f0
Mar 10 02:37:03 kvm kernel: [<ffffffff81144a99>] ? get_user_pages+0x49/0x50
Mar 10 02:37:03 kvm kernel: [<ffffffff81189fa7>] ? search_binary_handler+0x137/0x370
Mar 10 02:37:03 kvm kernel: [<ffffffff8118a4f7>] ? do_execve+0x217/0x2c0
Mar 10 02:37:03 kvm kernel: [<ffffffff810095ea>] ? sys_execve+0x4a/0x80
Mar 10 02:37:03 kvm kernel: [<ffffffff8100b4ca>] ? stub_execve+0x6a/0xc0
Mar 10 02:37:03 kvm kernel: Disabling lock debugging due to kernel taint

    

Answer 1

Uau,

O link-dest só pode ter um caminho local (assim como os hard links nos sistemas de arquivos tradicionais) porque eles realmente precisam apontar para o exatamente o mesmo inode . Toda vez que você acessa esse inode você aumenta a contagem aberta (o que impede que ele seja limpo), e quando você empilha isso através de um par de processos ssh e lança uma grande e impaciente VM não qualificada que ... , Eu esperaria que as coisas quebrassem.

Eu tenho algumas perguntas:  - Por que exatamente você está montando o instantâneo LV no lugar do original    disco? Espaço? Você poderia passar direto pelo túnel ssh, mas    Provavelmente seria melhor quebrar e então rsync.  - Por que a curiosa dependência de um link físico está causando problemas na fonte?

Eu faço algo não totalmente diferente de algumas caixas VM, mas é com várias nas4free (ou seja, caixas ZFS) que são alvos iScsi para os hosts da VM. Os snaps do ZFS são instantâneos, por mais persistentes que eu tenha espaço, familiares para mim. Eu evito a replicação do ZFS como a praga dos links remotos, prefiro encaixar de maneira próxima e rsync os arquivos individuais remotamente bem e então encaixá-los no outro lado, isso fica um pouco complicado ocupado VMs (por exemplo, servidores Exchange) e é um pouco rápido e solto com consistência, mas existem outras maneiras de contornar isso. De qualquer forma, a maioria dos meus clientes tem um dia inteiro de fotos locais de 15 minutos e, no dia seguinte, o nas do meu escritório fica preso ... às vezes, muito mais rápido. Eu posso aparecer no local com uma nova máquina ou ligar remotamente a sua VM e eles realmente não sabem a diferença. Eu sei que jogar hardware não é uma resposta ideal, mas você realmente não teria a dor que sente agora (parece que você está realmente arriscando ambas as extremidades e não protegendo nenhum dos dois). Eu definitivamente estaria olhando para replicações iScsi NAS, HDFS, talvez DRBD, openstack-y vm para três + máquinas. (Eu não sei o quão grande você é) se eu estivesse no seu lugar.

Mas também tente dividir o trabalho em partes muito menores.

Ah, e nunca subestime a largura de banda de uma station wagon cheia de fitas.