Безопасно ли использовать жесткий диск во время работы rsync?

27

Я планирую сделать резервную копию моих больших жестких дисков rsync, и ожидаю, что это займет несколько дней. Безопасно ли использовать оригинальный жесткий диск (добавление файлов) во время rsyncработы? Или лучше оставить нетронутыми жесткие диски, пока они rsyncне закончатся?

— Googlebot
источник

1

Обратите внимание, что «использовать» может быть так же просто, как открыть браузер, ничего не делая. Браузеры, как правило, пишут много случайных вещей в своих каталогах данных. В худшем случае вы получите несогласованную резервную копию, то есть при восстановлении вы не сможете восстановить свои вкладки, ваши закладки могут исчезнуть (потому что база данных повреждена) или что-то в таком порядке.

— Йонас Шефер

Если у вас есть столько данных для резервного копирования, вы можете рассмотреть возможность разделения резервной копии на более мелкие части (поддеревья). Тогда только та часть, которая выполняется в данный момент, должна быть максимально статичной - и вы можете увидеть, какая это часть, следя за ходом выполнения сценария (с журналом и т. Д.). Поскольку это не одна большая резервная копия, некоторые ее части могут быть немного не синхронизированы с другими, но если вы запускаете одну большую резервную копию в работающей системе, это все равно произойдет.

— Джо,

34

Как уже указывали другие, во время работы rsync безопасно читать с исходного диска или использовать целевой диск вне целевого каталога. Также безопасно читать в целевом каталоге, особенно если целевой каталог заполняется исключительно запуском rsync.

В общем, небезопасно писать в директории с исходным кодом во время работы rsync. «Записывает» - это все, что изменяет содержимое исходного каталога или любого его подкаталога, включая обновления, удаление, создание файлов и т. Д.

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

Однако, есть простой способ обойти это: как только он закончится, снова запустите rsync с теми же параметрами. (Если у вас нет какого-то особенного параметра удаления; если вы это сделаете, будьте немного осторожнее.) Это приведет к повторному сканированию источника и передаче любых различий, которые не были обнаружены во время первоначального запуска.

Второй прогон должен передавать только различия, которые произошли во время предыдущего прогона rsync, и поэтому будет выполняться намного быстрее. Таким образом, вы можете свободно использовать компьютер во время первого запуска, но следует по возможности избегать внесения каких-либо изменений в источник во время второго запуска. Если вы можете, настоятельно рекомендуется перемонтировать исходную файловую систему только для чтения, прежде чем начинать второй запуск rsync. (Что-то вроде mount -o ro,remount /media/sourceдолжно сделать.)

— CVn
источник

7

Можно даже сделать третий прогон после второго: это может занять еще меньше времени ... ;-)

— gerlos

5

@gerlos Образец, кажется, появляется. Похоже, что можно просто продолжать выполнять команду rsync в конце каждого сеанса использования, и в течение нескольких дней это будет сделано в кратчайшие сроки.

— Монти Хардер

5

@gerlos Если вы перемонтируете только для чтения перед повторным запуском rsync, в этом не будет необходимости, и резервное копирование будет практически гарантированно согласованным, а время записи в исходную файловую систему будет минимальным.

— CVn

1

@gerlos Кстати, вот почему у меня есть запись, очень похожая @reboot root find / -print &>/dev/nullна мой системный crontab, для заполнения кеша. (Фактическая запись более сложна, чтобы учесть несколько особых случаев в моей конкретной системе.) Она использует некоторое количество оперативной памяти и некоторое время на настенных часах в начале после запуска, чтобы улучшить сканирование дерева каталогов.

— CVn

1

@ MichaelKjörling: интересная идея для кэширования иерархии. Но, может быть, вы должны запустить updatedb(создание базы данных locate) или slocate -u(то же самое, если у вас есть slocate)? Таким образом, вы по-прежнему кэшируете иерархию, но вы также создаете базы данных locate или slocate, что позволяет вам использовать эти команды для быстрого поиска большого количества файлов?

— Оливье Дюлак

22

Это зависит от используемой вами системы резервного копирования, но, как правило, плохая идея изменять содержимое устройства во время его резервного копирования. Тем не менее, вы можете прочитать его содержимое; это безопасная операция, даже если она замедлит процесс.

В вашем случае rsyncбудет создан список файлов, а затем начнется резервное копирование. Поэтому любой файл, добавленный вами на исходный жесткий диск после запуска резервного копирования, не будет скопирован.

Я не использую устройство вообще во время резервного копирования. Это более безопасный способ получения быстрого и надежного резервного копирования.

— dr01
источник

14

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

— Мартин Уединг

15

Во время работы безопасно считывать данные из исходных областей rsync, но если вы что-либо обновите, rsyncскорее всего , созданная / обновленная копия будет несовместимой:

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

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

Если вы используете LVM для разделения системы хранения, вы можете использовать временный снимок для резервного копирования на определенный момент времени. Это требует, чтобы у вас было достаточно места в группе томов, чтобы создать том снимка, достаточно большой, чтобы вместить все изменения, которые произойдут в течение времени, необходимого снимку. Обратитесь к документации LVM (или одному из множества онлайн-примеров: найдите «LVM snapshot backup» или подобное) для получения более подробной информации.

Даже без LVM некоторые файловые системы сами поддерживают моментальные снимки - так что вы можете также рассмотреть эту опцию.

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

— Дэвид Спиллетт
источник

Мне больше нравится ваш ответ, потому что вы вдаваетесь в подробности о том, что произойдет, если файлы будут изменены. Вы не только предоставляете альтернативу, но и устраняете несоответствия, которые она может вызвать (пропущено обновление, предупреждение об отсутствующем файле и т. Д.). В моей ситуации использование rsync для создания длинной резервной копии и последующего ее обновления несколько дней спустя не имеет большого значения, и это также похоже на ситуацию ОП. Не похоже, что он / она требует резервного копирования уровня предприятия с первого раза, а просто хочет использовать компьютер в то же время. Я говорю, просто запустите rsync во второй раз, чтобы перехватить обновленные файлы.

— 17

11

Исходный HDD может читать все, пока rsync.
Исходный жесткий диск может записывать любой контент, не связанный с контентом rsync.
Целевой HDD может читать все, пока rsync.
Целевой HDD может записывать что угодно, пока rsync с условием, чтобы было достаточно места, зарезервированного для синхронизированного содержимого

Конечно, в любом из случаев произойдет снижение производительности.

— Сверхразум
источник

0

Все текущие ответы говорят о безопасности данных с точки зрения согласованности и предполагают идеальное оборудование.

Еще одна вещь, которую следует учитывать, - это сама аппаратная безопасность. Если у вас есть жесткие диски без резервных копий, которые могут оказаться на грани выхода из строя (вы, возможно, даже не знаете), и вы делаете начальную полную резервную копию, не используйте ее. Даже не монтируйте его, если данные критичны. Вы можете использовать такой инструмент, как ddклонирование диска в качестве блочного устройства. То, что вы не хотите, чтобы головка диска искала и, возможно, записывала, пока вы пытаетесь сделать резервную копию Плюс ddдолжно быть быстрее для начального резервного копирования, так как он просто копирует биты по порядку (если диск в основном не заполнен, я полагаю, что rsync также выиграет в начальном случае).

Для последующих инкрементных резервных копий rsync - отличный выбор, и я согласен с другими ответами на 100%.

— Zak
источник

1

Если СМИ являются маргинальными или даже потенциально маргинальными, ddэто не лучший выбор. Используйте ddrescueвместо этого; он намного лучше справляется с частичными сбоями. Но это не было соображением в первоначальном вопросе.

— CVn

@ MichaelKjörling Это хороший момент.

— Зак