Резервное копирование данных ext4 в раздел exFAT
У меня есть компьютер под управлением Ubuntu 16 с кучей жестких дисков ext4, смонтированных в общей папке samba, которую я использую в качестве локального NAS.
Я не хочу использовать RAID, потому что я хочу иметь возможность выключить компьютер, взять один из этих жестких дисков и подключить его к другому компьютеру в другом географическом месте, чтобы он сразу работал.
Изначально я хотел использовать exFAT для разделов, потому что он более универсален, чем ext4 (я могу подключить его к Windows и macOS без установки стороннего программного обеспечения), но, поскольку для этого формата нет журналирования, я решил против этого.
Но теперь я хочу добавить подпрограмму резервного копирования с помощью rsync + cron, чтобы содержимое каждого жесткого диска ext4 регулярно копировалось на другой жесткий диск ext4 аналогичного размера (это в дополнение к облачному резервному копированию), поэтому мне интересно:
Можно ли использовать формат exFAT на резервных жестких дисках? Таким образом, данные разделов ext4 будут сохранены в разделах exFAT. Или вы бы посоветовали против этого? Почему?
Я думаю: таким образом я получаю журналирование на основном диске ext4 и могу вывести резервный диск в другое место и заставить его работать непосредственно на Windows / macOS всякий раз, когда мне нужно .
Бонусный вопрос: я все еще довольно новичок в Linux, так что rsync + cron - подходящий инструмент для этого типа задания резервного копирования?
1 ответ
Я советую вам не использовать rsync. Вы должны использовать rdiff-backup, Duplicity или Borg Backup.
rsync отлично подходит для зеркалирования, то есть синхронизации папок. Однако вы, вероятно, хотите сделать резервную копию. Представьте, что вы случайно удалили что-то, и ваша задача cron запускает синхронизацию, прежде чем вы можете ее остановить. Это означает, что вы просто потеряли эти данные, хотя думали, что у вас есть резервная копия. Но у тебя было только зеркало. Теперь, если вы уже сделали копию этой копии, вы можете вернуть свои данные, если они еще не перезаписаны. Но если вы не заметите свою ошибку в течение некоторого времени, ваши данные будут потеряны.
Теперь есть переключатель rsync (-b / --backup), чтобы предотвратить это. Но вам, вероятно, все еще лучше использовать инструмент, который на самом деле предназначен для создания резервных копий.
rdiff-backup является таким инструментом. Однако ему не хватает шифрования.
Duplicity предлагает шифрование. Я, однако, сделал личный опыт, что он не восстанавливает данные надежно. То есть, когда я пытался вернуть папку в предыдущее состояние, один файл, который меня действительно волновал, просто не был восстановлен. И я знаю, что этот файл существовал раньше в течение нескольких месяцев, потому что я просто случайно облажался, прямо перед тем, как захотел восстановить его. Duplicity не позволила бы мне восстановить этот файл, и когда я попытался вернуть папку в разные моменты времени, со всем, с чем мне было бы хорошо, потому что в этом файле не было серьезных изменений в течение нескольких месяцев, он просто не справился. t поместил этот файл в восстановленную папку и даже не напечатал подсказку, указывающую, что этот файл отсутствовал.
Я не знаю, действительно ли это проблема с Duplicity или проблема с Deja Dup, поскольку я использовал Deja Dup (который использует Duplicity, который, в свою очередь, использует rsync, кстати) для резервного копирования. Однако я попытался восстановить файл / папку как через Deja Dup, так и напрямую через Duplicity. Это не сработало.
Поскольку мое доверие к Дежа Дупу уже исчезло после того, как я сам столкнулся с проблемой, я переключился на Резервное копирование Borg, которое я рекомендую вам тоже.
Borg Backup требуется немного времени, чтобы начать, но как только вы поймете, как это работает, это здорово. Он предлагает управление версиями, шифрование, сжатие и дедупликацию. Резервное копирование с помощью Borg Backup выполняется быстрее, чем с помощью Deja Dup, и вы можете наслаждаться удивительными функциями, такими как возможность монтировать хранилище резервных копий.
То есть вы запускаете команду монтирования, а затем вводите местоположение, в которое вы монтировали свой репозиторий. После этого вы увидите список меток резервного копирования в виде папок. Вы можете войти в любую из этих папок и искать свои файлы. Нет необходимости восстанавливать их ревизию за ревизией. Они просто все в конном репо.
Это означает, что вы можете использовать обычные функции и инструменты командной строки для этих ревизий. Например, недавно я узнал, что случайно удалил файл рабочего стола Firefox некоторое время назад. Не замечал неделями. Простой
ll */home/christoph/.local/share/applications/firefox.desktop
в смонтированном каталоге дал мне список всех ревизий, содержащих этот файл. Я просто скопировал самый новый. Но если вы хотите, вы можете взять этот список и проверить результаты, чтобы увидеть, что изменилось, без необходимости что-либо восстанавливать. Кроме того, установка и поиск в репозитории были намного быстрее, чем Deja Dup, чтобы выяснить, какой файл пропал.
Если вы используете резервное копирование Borg, оно фактически будет отслеживать владение и разрешения, при этом файловая система в хранилище резервных копий не будет поддерживать владение или разрешения, поскольку они инкапсулированы Borg.
Борг может быть отлично использован при выполнении заданий cron. Это всего лишь одна команда, которую вы должны выполнить. Необходимо указать имя архива, которое должно быть различным для каждой резервной копии. Если вы вводите команды вручную, вы можете написать что-то более значимое. Я просто использую date +%c для имен архивов, потому что мои резервные копии создаются автоматически.
Сохранение вашей первой резервной копии на ФС с ведением журналов, безусловно, хорошая идея. Поскольку вы затем создаете только другие резервные копии, и это не страшно, если вам нужно выбросить ФС, ваша вторая резервная копия отключена, потому что она была скомпрометирована при отключении питания, использование ФС без журналирования для нее приемлемо.
Вы можете синхронизировать эту вторую резервную копию с первой через rsync. В этом нет никаких проблем, поскольку вы уже убедились, что можете вернуться к предыдущим версиям через Borg Backup, и - если хотите - Borg также уже позаботился о шифровании.