Назад | Перейти на главную страницу

Ошибки чтения при резервном копировании в NFS через rsync

Я делаю резервную копию Linux-сервера на NAS, смонтированный через NFS. Я использую rsync (как часть схемы вроде http://www.mikerubel.org/computers/rsync_snapshots/ с жесткими ссылками). То есть я ssh в machine_being_backed_up, запускаю свою команду rsync, она выполняет резервное копирование файлов примерно на час, а затем замораживает сервер (например, необходимо физически перезагрузить; что очень неудобно, поскольку серверы в другом здании по всему городу, поэтому требуется время для перезагрузки) ошибка в конце (с анонимными именами):

some/path/file1.gz
rsync: read errors mapping "/home/some/path/file1.gz": Input/output error (5)
some/path/file2.gz
rsync: read errors mapping "/home/some/path/file2.gz": Input/output error (5)
some/path/file3.gz

Вероятно, это указывает на то, что на жестком диске машины, для которой я пытаюсь создать резервную копию, есть несколько неисправных секторов, верно? Или эта ошибка могла возникнуть из-за слишком медленного соединения NFS или неправильного выбора параметров при монтировании моего диска NFS (установка с параметрами rw, soft, intr)? Есть ли способ заставить эти ошибки ввода / вывода просто пропускать / отказывать эти файлы и не замораживать систему (чтобы мне не пришлось ехать через город, чтобы перезагрузить сервер)?


Обновление: вчера я включил SMART и вчера провел короткие и длинные самотестирования, которые не выявили ошибок (вчера я не мог упомянуть об этом, так как длительный тест закончился около 7 часов, а компьютер вышел из строя около полуночи, поэтому я мог войти в систему до сегодняшнего утра, когда я мог бы включить -сайт перезагрузка).

Также я попытался выполнить синхронизацию рассматриваемых файлов с другим разделом на том же диске и не получил никаких ошибок. Теперь я пытаюсь выполнить rsync напрямую с NAS (вместо того, чтобы монтировать NAS с помощью NFS).


Обновление (3 октября): я переместил жесткий диск на другой компьютер, и прошло около 2 недель без ошибок. Пока в старой машине ежедневно возникали ошибки такого типа. Я предполагаю ошибки материнской платы или памяти на другом компьютере (не было времени, чтобы полностью диагностировать и определить проблему).

Тот факт, что это физически "зависает", указывает на то, что это признак аппаратной ошибки. Я бы не ожидал, что плохие сектора приведут к зависанию машины, так что это может быть что-то менее легкое для диагностики.

Чтобы узнать, не является ли проблема диском, попробуйте прочитать затронутые файлы локально (войдите через SSH и используйте cat /home/path.to.file > /dev/null), хотя, если это работает, это не обязательно означает, что поверхность диска в порядке (она может быть пограничной, а иногда и читаемой, в других случаях нет). Если вы еще этого не сделали, запустите инструменты мониторинга SMART и следите за такими вещами, как увеличение числа переназначений секторов - это будет указывать на то, что поверхность диска не в форме вершины вершины (переназначение нескольких секторов не является необычным для современных массивных дисков, но многие указывают на серьезная проблема).

Это могло быть повреждение файловой системы, но опять же, я не ожидал, что это полностью повесит машину - или, если бы это было настолько плохо, что привело бы к сбою драйвера файловой системы, я бы ожидал сообщения о панике ядра на консоли, а не остановки машины. Вы можете использовать fsck, чтобы проверить это, но убедитесь, что все, что вы в настоящее время можете прочитать, зарезервировано на случай, если повреждение настолько велико, что попытка исправить его усугубит ситуацию (это редко, но я видел, как это происходит, особенно если вы с использованием экспериментальной файловой системы или бета-версии, а не испытанной + проверенной версии).

Еще одна вещь, которую следует проверить при зависании оборудования, - это то, что процессор и оперативная память в порядке. Они могут быть неисправными и перегреваться - не настолько, чтобы вызывать проблемы при нормальной работе, быть дополнительной нагрузкой, вызванной запуском rsync в течение некоторого времени, выталкивая что-то за край. Это может быть выявлено при запуске теста памяти и теста на «прожиг» ЦП, если это проблема. Ваш контроллер ввода-вывода также может быть подозреваемым, хотя я не уверен, как вы подойдете к этому тестированию.

У меня возникла та же проблема, и я получил такое же сообщение об ошибке при копировании большого размера (много МБ) с помощью rsync и NTFS под Распбиан GNU / Linux 8.0 (Джесси). Раньше диск работал под Windows без минут. Я рассудил, что проблема может быть связана с программным обеспечением.

  • Сначала я попытался прочитать файл последовательно, предполагая, что NTFS реализация не поддерживала mmap(2) правильно. Это не удалось точно так же.
  • Затем я попытался заменить основанный на ядре NTFS реализация с NTFS-3G. Это позволило мне без проблем скопировать файл.

Похоже, у вас проблемы с файловой системой или жестким диском на исходной машине, и он не работает. rsyncпод контролем. Попробуй это:

$ cp /home/some/path/file1.gz /home/some/path/file1_bak.gz
...

и беги rsync снова (с новыми файлами), чтобы проверить, работает ли он. Если нет, взгляните на --exclude или --exclude-from возможность резервного копирования всех оставшихся данных Срочно, затем проверьте состояние жесткого диска с помощью SMART, бегать fsck если необходимо.