Атомарность резервного копирования файловой системы Linux

Question

На моей машине с Linux я использую самодельный скрипт резервного копирования, который на самом деле представляет собой несколько вызовов rsync. Я проверил свои восстановления, и все, кажется, работает, но есть ли возможные проблемы с этой настройкой?

Моя главная проблема - атомарность этой резервной копии. Насколько я знаю, файлы в Linux не заблокированы. Можно ли скопировать файлы, если они частично записаны? Возможно ли, что базы данных, XML-файлы или любые другие часто записываемые файлы, имеющие структуру или синтаксис, могут оказаться поврежденными или непригодными для использования в месте резервного копирования?

Answer 1

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

Если вы используете LVM, то функция моментальных снимков делает это гораздо менее обременительным, поскольку вам нужно останавливать службы только на время, необходимое для создания моментального снимка только для чтения, который является практически мгновенным. Вы берете резервную копию из моментального снимка, а затем удаляете ее, пока новая не понадобится для следующего запуска резервного копирования. См. Http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html для получения более подробной информации.

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

Answer 2

Что касается баз данных, иногда безопаснее создать дамп данных, а затем сделать резервную копию дампа. Например, MySql поставляется с этим инструментом mysqldump, который может выполнить это.

Я использую Bacula для создания своих резервных копий, и у меня настроен запуск mysqldump для выгрузки баз данных в каталог для дампов, а затем bacula создает резервные копии этого каталога. Я делаю нечто подобное для SVN.

У меня нет автоматизированной процедуры восстановления, но, по крайней мере, у меня есть данные в формате, который легко импортировать в MySql и, возможно, в другие базы данных, поскольку файл дампа - это просто SQL

Answer 3

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

# mysqldump --all-databases -u user -p | bzip2 -c > mysqlbackup.sql.bz2
# <rsync stuff here>

Затем загрузить его в новую базу данных

# bzip2 -d mysqlbackup.sql.bz2
# mysql -u user -p < mysqlbackup.sql

Чтобы еще больше облегчить любую паранойю, я иногда возвращаюсь к lsof -F | grep <keyword> чтобы увидеть, действительно ли файл, который я хочу передать, используется или открыт. Если lsof вернет ноль, то я знаю, что я прав, чтобы продолжить. Вы можете использовать его для поиска открытой таблицы MySQL, когда MySQL пишет в нее. Как только lsof вернет ноль, вы можете продолжить передачу файлов.

Answer 4

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