Я делаю резервную копию 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 без минут. Я рассудил, что проблема может быть связана с программным обеспечением.
Похоже, у вас проблемы с файловой системой или жестким диском на исходной машине, и он не работает. rsync
под контролем. Попробуй это:
$ cp /home/some/path/file1.gz /home/some/path/file1_bak.gz
...
и беги rsync
снова (с новыми файлами), чтобы проверить, работает ли он. Если нет, взгляните на --exclude
или --exclude-from
возможность резервного копирования всех оставшихся данных Срочно, затем проверьте состояние жесткого диска с помощью SMART
, бегать fsck
если необходимо.