Насколько я знаю, чтобы создать полезную и последовательную резервную копию, необходимо задействовать приложение, обрабатывающее данные, подлежащие резервному копированию.. Я хотел бы подтвердить свои выводы с другими системными администраторами.
Рассмотрим ситуацию, когда в приложении есть файл, открытый для чтения / записи, и, пока он открыт, отдельный процесс резервного копирования читает файл. (И это разрешено - если бы мы использовали стада, и обязательное они вместо консультативный при этом нам все равно придется задействовать приложение). Следует общепризнанно, что резервная копия, созданная для этого открытого файла, может быть несовместимой.
Использование моментальных снимков на уровне файловой системы не может полностью решить эту проблему; поскольку мы не можем гарантировать, что в момент моментального снимка т все приложения записали согласованные файлы на диск (предположим, что т мы можем очистить все буферы).
Таким образом, при создании правильного плана резервного копирования нужно всегда помнить о том, какие приложения записывают данные и как они это делают, и убедитесь, что они записывают согласованные файлы на диск, прежде чем делать снимок / резервную копию.
Вы согласны со мной, или я сделал принципиальные ошибки, размышляя над этим?
(Пожалуйста, не отвечайте на этот вопрос какими-либо конкретными HOWTO, поскольку речь идет об общих принципах "высокого уровня". Кроме того, чтобы убедиться, что это не насчет БД, так как там проблема уже решена).
Кажется, вы хорошо разбираетесь в проблемах.
Стандартный подход к моментальному снимку, который я видел, - это выключение служб, которые будут записывать в файловую систему, разрушение моментального снимка и перезапуск служб. Бэкап на стороне не пишется.
Другой подход - это возможность экспортировать набор данных на определенный момент времени из приложения. Затем сделайте резервную копию экспортированных данных. Это один из подходов, который могут использовать базы данных. Данные могут быть преобразованы во время экспорта, поэтому могут потребоваться дополнительные шаги для импорта данных.
Альтернативный подход, который я использовал с базами данных, заключается в том, чтобы помечать файлы как резервные копии во время их копирования. Это может отложить обновления во время резервного копирования или может позволить воспроизвести изменения в более позднее время. Для этого требуются журналы изменений, которые также необходимо резервировать.
Я обычно исключаю файлы базы данных из своих стандартных резервных копий и использую один из альтернативных подходов для получения данных на определенный момент времени из базы данных.
Тщательно спланируйте, прежде чем восстанавливать базу данных. Мне редко приходилось восстанавливать полную базу данных до определенного момента времени. Холодное резервное копирование (выключение базы данных) может быть подходящим для базы данных, используемой во время обучения. Сожалею, что предоставил аналогичный откат для тестирования баз данных.
Вы согласны со мной, или я сделал принципиальные ошибки, размышляя над этим?
По сути, я хотел бы обратить внимание на одно важное соображение: тот факт, что отключение электроэнергии все еще случается, очень помогает при резервном копировании. Любое приложение, которое обрабатывает отключение электроэнергии (т. Е. Резкую потерю ЦП и ОЗУ, включая дисковый кеш), также может выполнить восстановление из моментального снимка. Любое приложение, которое этого не делает - да, в данной ситуации вы правы - требует особой осторожности.
Это решенная проблема для многих классов хранилищ данных - в частности, для хранилища данных, которое описывается как «журналируемое», или для любого энергонезависимого, не игрушечного движка базы данных.
Все может усложниться, когда одно приложение использует несколько файловых систем, но некоторые методы моментальных снимков могут поддерживать их согласованность.
Я думал о том же. Возможно, хорошим решением будет использование CQRS и источников событий или любой другой стратегии только с добавлением. Если вы сохраняете вложение в файловой системе, а не в хранилище событий, вам следует пометить файлы для удаления и удалить их только после резервного копирования. Поэтому, если удаление происходит во время резервного копирования, это не повлияет на целостность резервной копии. Что касается баз данных запросов, я думаю, что лучше перестроить их на отдельном сервере, используя резервную копию хранилища событий, чтобы это не повлияло на производительность чтения вашего запущенного приложения, и вы можете быть уверены, что это момент времени. тоже последовательный. Я все еще не уверен, можно ли сделать последовательную резервную копию в обычном приложении, не останавливая его.