Является ли rsync -delete безопасным в случае сбоя диска


3

У меня есть два жестких диска с данными на моем сервере Linux, и я использую второй в качестве резервной копии для первого диска.
я использую Rsync для этой цели. Примером может быть:

rsync -r -v --delete /media/disk1/ /media/disk2/

Это делает то, что он копирует каждый файл / каталог из / СМИ / disk1 / в / СМИ / disk2 / но также удаляет любую разницу. Например, допустим, что файлы A и B, но не файл C, включены disk1 и на disk2 нет файлов A и B, но есть C. В результате после команды на disk2 У меня были бы файлы A и B, но файл C был бы удален, как и на disk1 ,

Теперь, довольно катастрофический сценарий приходил мне в голову; Что если диск1 умирает, система продолжает работать, так как системные файлы находятся на моем системном диске, но когда rsync пытается сделать резервную копию моих данных на disk2 из сломанного disk1 удаляет все файлы из disk2 потому что он не может ничего читать на disk1 ,

Это возможный сценарий, или есть защита от него встроенного Rsync ?


Это не резервная копия. Если ваши данные повреждены / стерты из-за вируса / программного или аппаратного сбоя / ошибки человека, ваша команда также удостоверится, что они также повреждены / стерты на втором диске.
gronostaj

Ответы:


3

Реально, в этом случае ядро ​​взбесится, и вы получите кучу ошибок дискового ввода-вывода, прежде чем rsync что-нибудь удалит. Но тогда, если вы перезагрузитесь, возможно, что / media / disk1 будет пустым и размонтированным ... Итак ...

В вашем скрипте rsync просто убедитесь, что вы не запускаете rsync, если в / media / disk1 нет файлов. Простой способ сделать это будет:

ls /media/disk1/SomeFileYouKnowExists || exit
rsync ....

Это приведет к завершению работы сценария перед запуском rsync в случае, если целевой файл не существует.


Однажды у меня был сбой одного диска в настройке LVM, и сервер продолжал работать, поэтому я не буду ставить на остановку ядра, возможно, это произойдет, если произойдет сбой системного диска. & Lt; br & gt; Что касается кода, который вы предложили, я создаю резервные копии огромного количества файлов, которые меняются, и я не могу отследить все изменения.
enedene

Это связано с тем, что при сбое одного диска в LVM другие диски могут продолжать обслуживать данные, и ядро ​​может не заметить, пока не попытается прочитать данные с неисправного диска.
Flimzy

Для меня это также звучит так, как будто rsync не подходит для вашей работы - вам может быть лучше с реальный резервное приложение.
Flimzy

@Flimzy, вы, вероятно, правы в отношении LVM, но я не уверен, что это произойдет и с несистемными дисками, поскольку это еще не произошло. На данный момент rsync хорошо выполняет свою работу, поэтому я спрашиваю, есть ли опасность, если нет, продолжу ли я ее использовать, потому что это легко и практично для меня. Я также не удивлюсь, если более сложные решения используют rysnc в фоновом режиме.
enedene

1
Конечно, некоторые системы резервного копирования могут использовать rsync в качестве метода передачи, но это не повод доверять rsync для создания ценных резервных копий. Это все равно что сказать: «Некоторые системы резервного копирования используют HTTP, поэтому я просто загружу свои файлы в Gmail через HTTP в качестве метода резервного копирования». «Настоящая» система резервного копирования обеспечит версионные резервные копии и историю - что сделает ваш вопрос практически устаревшим. :)
Flimzy

2

Из руководства по rsync:

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


1
Включает ли это весь возможный диапазон ошибок диска или только при серьезном сбое? & Lt; br & gt; Ошибки на диске могут быть странными, вы можете увидеть список некоторых файлов, но часть его может быть повреждена и так далее.
enedene
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.