Erro IO no rsync ao fazer backup diário

Erro IO no rsync ao fazer backup diário

Eu tenho um servidor NAS de amostra (QNAP TS-210), com Linux integrado muito limitado (embora um pouco reforçado com Optware/IPKG). Eu sou um novato em Linux. Depois de pesquisar na Internet, consegui escrever meu próprio script de backup, usando rsync para sincronizar arquivos entre o disco rígido NAS e unidades USB externas e com CRON para executar esse script periodicamente.

Tudo estava bem até poucos dias antes. Os e-mails gerados pelo script de backup começaram a conter informações IO error encountered -- skipping file deletionde vários recursos (pastas) que estavam sendo copiados. Quando executo o mesmo script via SSH, recebo muitas linhas de erro dizendo " cannot send file with empty name in...", seguidas de " rsync error: some files/attrs were not transferred (see previous errors)".

100% do conteúdo que estou fazendo backup vem do Windows (eu uso NAS apenas para fazer backup dos meus próprios computadores). Este sistema não permite criar um arquivo com nome vazio. Esse problema existe há apenas alguns dias e não modifiquei meus backups por mais de algumas semanas (férias). Portanto, este deve ser um problema do Linux (integrado no meu NAS).

A pergunta é: o que pode fazer com que os arquivos apareçam com nomes vazios? Como posso me livrar deles (quando vou cdpara a pasta mencionada no relatório rsync e faço ls -ls, não vejo nada como "arquivo com nome vazio"), para que a próxima passagem do rsync acabe sem tais erros. E finalmente – como evitar esses arquivos no futuro?

Responder1

Não acho que isso seja culpa do rsync. Acho que você marcou isso corretamente como um problema no nível do kernel, já que o código relevanteflist.cdas fontes do rsynclê:

1729         for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730                 unsigned name_len;
1731                 char *dname = d_name(di);
...
1746                 if (dname[0] == '\0') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

Na verdade, essa linha de código foi adicionada pelo desenvolvedor rsyncem agosto de 2007especificamente para este caso:

If readdir() gives us an empty name, reject it.

Em outras palavras, readdir()a própria (a função do kernel que retorna a lista de arquivos em um diretório) retornou uma entrada com uma string vazia. Segundo as regras, isso nunca deveria acontecer. Citando doEspecificação do grupo aberto:

The readdir() function shall not return directory entries containing empty names.

Parece que foi algum tipo de problema transitório, porque ele desapareceu no momento em que você fez um lsnaquele diretório (que também teria sido usado readdir(), ele desapareceu).

Então a resposta às suas perguntas:

  1. A causa parece ser um sistema de arquivos corrompido - qualquer coisa, desde bug no driver do kernel até falha de hardware, pode ser responsável.Também pode valer a pena verificar se o diretório que você está sincronizando novamente é acessado via link simbólico ou cruza um limite de rede que pode estar com problemas.

  2. Para se livrar deles: a lista de verificação usual de reparo do sistema de arquivos: fsck, etc.

  3. Para evitar no futuro: suponho que você poderia dizer ao seu script para forçar uma listagem recursiva de antemão - mas como você já está sendo notado (e voltou das férias), parece que a coisa certa a fazer é ficar de olho e pule na caixa se isso acontecer novamente.

Espero que tenha sido útil, boa sorte!

informação relacionada