Файловая система Linux копирует атомарность
На моей машине Linux я использую самодельный резервный сценарий, который является на самом деле несколькими вызовами rsync. Я протестировал свои восстановления, и все, кажется, работает, но является там какими-либо возможными проблемами с этой установкой?
Мое основное беспокойство является атомарностью этого резервного копирования. Насколько я знаю, файлы в Linux не заблокированы. Файлы могут быть скопированы если только частично записанный? Действительно ли возможно, что базы данных, XML-файлы или какие-либо другие часто записанные файлы, которые имеют структуру или синтаксис, могли закончиться поврежденные или неприменимые в местоположении резервирных копий?
4 ответа
Для атомарного резервного копирования идеально необходимо остановить весь доступ для записи к области, являющейся резервным копированием, что означает останавливать все сервисы, которые могли бы записать в них.
При использовании LVM затем, средство фиксации мгновенного состояния процесса делает это намного менее обременительным, поскольку только необходимо остановить сервисы на отрезок времени, это берет для создания снимка только для чтения, который почти мгновенен. Вы берете резервное копирование от снимка и затем удаляете его, пока новый не необходим для следующего выполненного резервного копирования. См. http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html для большего количества детали.
Не оставляйте снимок (снимки) активным больше, чем Вам нужно к хотя, поскольку существуют последствия производительности (хотя это обычно намного меньше проблемы, затем имеющей необходимость иметь целый период времени простоя в то время как выполненные резервные копии).
Относительно баз данных иногда более безопасно вывести данные и затем скопировать дамп. Например, MySql идет с этим инструментом mysqldump, который может выполнить это.
Я использую Бакулюмы, чтобы сделать мои резервные копии, и мне настроили его для выполнения mysqldump для дампа баз данных в каталог для дампов, и затем бакулюмы копируют этот каталог. Я делаю что-то подобное для SVN.
Мне не автоматизировали процедуру восстановления, но по крайней мере у меня есть данные в формате, легком импортировать в MySql и вероятно в другие базы данных, так как файлом дампа является просто SQL
Да, они могут все еще быть скопированы. Как предложенный выше я вывел бы базы данных в файл, bzip их для хорошего сжатия затем 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 возвращает пустой указатель, можно продолжить передавать файлы.
Согласно этой странице, необходимо поддержать базу данных в файл и затем остановить его перед rsync. Это не идеально, поскольку необходимо скопировать целую базу данных каждый раз. Специализированная процедура резервного копирования базы данных является лучшей.