☰

A maneira mais eficiente de reduzir um backup que usa hardlinks

tag-icon • tag-icon command-line filesystems backup parallelism
A maneira mais eficiente de reduzir um backup que usa hardlinks

Eu tenho um disco de backup que contém centenas de backups da mesma máquina em datas diferentes. O backup foi feito com rsync e hardlinks, ou seja, se um arquivo não muda o script de backup apenas faz um hardlink para o arquivo em um backup mais antigo. Portanto, se um arquivo nunca for alterado, você terá essencialmente uma cópia no disco de backup, mas digamos 100 hardlinks para ele em cada diretório representando o backup de cada data (digamos back-1, back-2, ... back-n). Se eu quiser diminuir, excluo um subconjunto deles, mas não todos. Suponha que eu queira deletar back_5, back_6, ... back_10(só como exemplo, no meu cenário real existem muitos mais). Então tento paralelizá-lo via:

echo back_5 back_6 back_10 | xargs -n 1 -P 0 rm -rf

Isso leva várias horas. Então, existe alguma maneira mais rápida de fazer isso?

Responder1

Não consigo ver como você usaxargsdesta forma é tudo menos lento. Minha página de manual diz que -P é o número de processos e -n é o número de argumentos. Não há valor especial para -P0, então isso provavelmente será ignorado (ou, se respeitado, você obterá zero processos, o que explicaria 24 horas de nada!). E -n1garante que você obtenha umexecutivo(2) para cada nome de arquivo, que é o mais lento possível.

Duvido que paralelizar esse trabalho lhe traga muita coisa. eu pensaria apenas

$ echo filenames ... | xargs rm -rf

seria suficiente. Você pode experimentar valores como -P4quiser. Pornãolimitando o número de argumentos de linha de comando, você minimiza as invocações /bin/rme permite que ele prossiga em série pelo cache de disco.

Responder2

O df está relatando um número pequeno porque você está excluindo principalmente diretórios, que são relativamente pequenos. Além disso, dependendo do sistema de arquivos, as alterações nos diretórios e as alterações no número de links para um arquivo são registradas em diário e/ou sincronizadas com o disco imediatamente, pois são críticas para a recuperação de falhas e, portanto, mais lentas.

Na verdade, isso é uma prova da eficiência da sua vinculação!

Responder3

Na minha experiência, a melhor maneira de acelerar os backups baseados em rsync+hardlink era diminuir o número de arquivos que você possui.

Um grande número de arquivos pequenos retarda o rsyncbastante.

Se você puder organizar seus dados de forma que seus diretórios, em sua maioria de arquivos pequenos e somente leitura, fiquem tarvermelhos, você verá uma velocidade significativa em seu script de backup. (Com ferramentas como archivemount, você pode acessar esses arquivos sem extraí-los).

Paralelizar o script de backup provavelmente não ajudará ou poderá até mesmo retardá-lo (o acesso previsível ao disco é mais ideal).

Responder4

Esta é também uma resposta baseada na experiência, e não apoiada em dados concretos.

Acho que ao excluir muitos arquivos em árvores semelhantes com muitos links cruzados, parece mais rápido excluir subárvores isoladas em paralelo. Deixe-me tentar explicar com um diagrama:

topdir1
    |-a1
    |-b1
    |-c1

topdir2
    |-a2
    |-b2
    |-c2

topdir3
    |-a3
    |-b3
    |-c3

Em vez de excluir topdir1, topdir2, topdir3em paralelo, minha impressão é que é mais rápido excluir a1, b1, c1em paralelo e depois passar para a2, b2, c2e assim por diante. (Minha teoria para isso é que a desvinculação paralela múltipla dos "mesmos" arquivos causa contenção para a contagem de referência do link do inode, mas enfatizo que não verifiquei isso com dados concretos.)

for topdir in *
do
    echo "Removing $topdir..."
    for sub in "$topdir"/*; do rm -rf "$sub" & done
    wait
    rm -rf "$topdir"
done

informação relacionada