IO Erro no rsync ao fazer backup diário

Question

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

Tudo estava bem até alguns dias antes. Os e-mails gerados pelo script de backup começaram a conter informações IO error encountered -- skipping file deletion para muitos recursos (pastas) que estão sendo armazenados em backup. Quando eu executo o mesmo script via SSH, recebo várias linhas de erro dizendo " cannot send file with empty name in... " seguido 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 o NAS apenas para fazer backup dos meus próprios computadores). Este sistema não permite criar um arquivo com nome vazio. Este problema existe por apenas alguns dias e eu não estava modificando meus backups por algumas semanas (férias). Então isso tem que ser o Linux (on-board my NAS).

A pergunta é: o que pode fazer com que arquivos apareçam com nomes vazios? Como posso me livrar deles (quando eu cd para a pasta mencionada no relatório rsync, e faço ls -ls , não vejo nada como "arquivo com um nome vazio"), então o próximo passo rsync acabaria sem tais erros. E finalmente - como evitar esses arquivos no futuro?

    

Answer 1

Eu 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 relevante de flist.c sources do rsync diz:

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] == '
If readdir() gives us an empty name, reject it.
') {
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 do rsync em agosto de 2007 especificamente para este caso:

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

Em outras palavras, readdir() em si (a função kernel que retorna a lista de arquivos em um diretório) retornou uma entrada com uma string vazia. Sob as regras, isso nunca deveria acontecer. Citando a especificação do Open Group :

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] == '
If readdir() gives us an empty name, reject it.
') {
1747                         io_error |= IOERR_GENERAL;
1748                         rprintf(FERROR_XFER,
1749                                 "cannot send file with empty name in %s\n",
1750                                 full_fname(fbuf));

Parece que foi algum tipo de problema transitório, porque desapareceu quando você fez um ls nesse diretório (o que também teria usado readdir() , ele desapareceu).

Então a resposta para suas perguntas:

1. A causa parece ser um sistema de arquivos corrompido - qualquer coisa, desde um bug do driver do kernel até uma falha de hardware, pode ser responsável. Também vale a pena verificar se o diretório em que você está rsync está acessando via symlink ou cruza um limite de rede que pode estar com problemas.

2. Para se livrar deles: a lista de verificação usual de reparos 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 está de férias), parece que a coisa certa a fazer é ficar de olho nele e pular na caixa se isso acontecer de novo.

Espero que isso tenha sido útil, boa sorte!