Я планирую сделать резервную копию моих больших жестких дисков к rsync
, и предполагаю, что это займет несколько дней. Безопасно ли использовать оригинальный жесткий диск (добавление файлов) во время rsync
работы? Или лучше оставить жесткие диски нетронутыми, пока не rsync
будет завершен?
решение1
Как уже указывали другие, безопасно читать с исходного диска или использовать целевой диск вне целевого каталога, пока rsync работает. Также безопасночитатьв целевом каталоге, особенно если целевой каталог заполняется исключительно запуском rsync.
Что не так?в целомбезопасно - этозапись в исходном каталогево время работы rsync. «Записывает» — это все, что изменяет содержимое исходного каталога или любого его подкаталога, включая обновления файлов, удаления, создание и т. д.
На самом деле это не будетперерывчто угодно, но изменение может быть или не быть фактически подхвачено rsync для копирования в целевое местоположение. Это зависит от типа изменения, от того, сканировал ли rsync этот конкретный каталог, и скопировал ли rsync файл или каталог, о котором идет речь.
Однако есть простой способ обойти это:После завершения запустите rsync еще раз с теми же параметрами.(Если только у вас нет какого-нибудь странного параметра удаления; если он у вас есть, то будьте немного осторожнее.) Это приведет к повторному сканированию источника и переносу всех различий, которые не были обнаружены во время первоначального запуска.
Второй запуск должен перенеститолькоразличия, которые произошли во время предыдущего запуска rsync, и поэтому будут завершены гораздо быстрее. Таким образом, вы можетеВо время первого запуска вы можете использовать компьютер в обычном режиме, но следует по возможности избегать внесения каких-либо изменений в исходный код во время второго запуска.Если вы можете, настоятельно рассмотритеперемонтирование исходной файловой системы только для чтенияперед началом второго запуска rsync. (Что-то вроде этого mount -o ro,remount /media/source
должно подойти.)
решение2
Это зависит от используемой вами системы резервного копирования, но в целом это плохая идея.изменитьсодержимое устройства во время резервного копирования. Однако вы можетечитатьего содержимое; это безопасная операция, даже если она замедлит процесс.
В вашем случае, rsync
создаст список файлов, а затем начнет резервное копирование. Поэтому любой файл, который вы добавите на исходный жесткий диск после начала резервного копирования, будетнетбыть скопировано.
Я вообще не использую устройство во время резервного копирования. Это более безопасный способ получить быстрое и последовательное резервное копирование.
решение3
Считывать данные из исходных областей во время работы безопасно rsync
, но если вы что-либо обновите, копия, которая rsync
создает/обновляет, скорее всего, будет несогласованной:
Если вы обновляете файл, который rsync уже просканировал, то он не увидит обновления до следующего запуска. Если вы обновляете файл, который он еще не просканировал, то изменение будет учтено в месте назначения. Если вы обновляете файлы, которые были и не были просканированы, то в месте назначения вы получите смесь старых и новых версий.
Если вы добавляете файл в каталог, который уже был отсканирован, на этот раз он будет пропущен в целевой копии. Если вы удаляете файл из каталога, который уже был отсканирован, на этот раз он останется в целевой копии. В зависимости от того, как вы вызываете,
rsync
все дерево может быть отсканировано в начале или может быть отсканировано пошагово по мере выполнения процесса синхронизации.В некоторых обстоятельствах
rsync
он увидит несоответствие и предупредит вас. Если вы удалите файл или подкаталог из каталога, который уже был просканирован сам по себе, но его содержимое не было просканировано, вы получите сообщение об ошибке об отсутствии объекта. В похожих обстоятельствах он иногда может (если размер и/или временная метка изменились) также предупредить об изменении файлов во время сканирования.
Для некоторых резервных копий эта непоследовательность может не представлять серьезной проблемы, но для большинства она будет иметь место, поэтому не рекомендуется пытаться синхронизировать активно изменяющийся источник.
Если вы используете LVM для разделения вашей системы хранения, вы можете использовать временный снимок для создания резервной копии на определенный момент времени. Для этого вам необходимо иметь достаточно места в группе томов для создания тома снимка, достаточно большого для хранения всех изменений, которые произойдут в течение того времени, пока требуется снимок. Проверьте документацию LVM (или один из многочисленных примеров в Интернете: найдите "LVM snapshot backup" или что-то подобное) для получения более подробной информации.
Даже без LVM некоторые файловые системы поддерживают моментальные снимки, поэтому вы можете рассмотреть и эту возможность.
Если вы хотите сделать резервную копию больших активных томов без длительного простоя и не можете использовать моментальные снимки, может быть достаточно запустить "живое" сканирование до конца, затем остановить доступ к тому и запустить другой процесс rsync, что может занять гораздо меньше времени (если изменений было очень мало, он просто просканирует дерево каталогов, а затем несколько обновленных файлов). Таким образом, период, в течение которого вам следует избегать изменений, может быть намного короче.
решение4
Во всех текущих ответах говорится о безопасности данных с точки зрения согласованности и при условии наличия идеального оборудования.
Еще одна вещь, которую следует учитывать, — это безопасность самого оборудования. Если у вас есть нерезервированные жесткие диски, которые могут быть на грани отказа (вы можете даже не знать об этом еще), и вы делаетеисходныйкомплексное резервное копирование не используйте его. Даже не монтируйте его, если данные критически важны. Вы можете использовать такой инструмент, какdd
клонировать диск как блочное устройство. То, что вам не нужно, чтобы головка диска искала и, возможно, записывала, пока вы пытаетесь сделать резервную копию. Плюс dd
должно быть быстрее для первоначальной резервной копии, поскольку оно просто копирует биты по порядку (если диск не заполнен в основном, я полагаю, rsync победит и в первоначальном случае).
Для последующего инкрементного резервного копирования rsync — отличный выбор, и я согласен с остальными ответами на 100%.