Надежность Снимка ВМ?

Question

Быстрый вопрос о резервных копиях снимков. У меня есть домашний проект, где у меня есть веб-приложение, подключенное к postgresdb на виртуальной машине. Я хочу простой способ создания резервных копий, поэтому я написал сценарий, который останавливает службу postgres, снимает виртуальную машину, а затем снова запускает службу. Я знаю, что веб-приложение не работает в течение этого периода, который ожидается, но все еще есть следующие вопросы:

1) Помимо установки какого-либо агента для управления базой данных для резервного копирования, является ли это разумным способом надежного резервного копирования системы?

2) Есть ли какие-либо проблемы, о которых я должен знать, когда использую такой метод?

Изменить: у меня есть программное обеспечение, которое затем берет снимок и сохраняет его с устройств, сохраняет последние несколько, и я убедился, что снимок возвращается в другой среде vCenter.

Answer 1

Как указывал ChrisInEdmonton, вы делаете снимки, а не резервные копии.

Резервное копирование подразумевает какое-то вторичное хранилище. Это может быть что угодно, от дискет или USB-накопителей, до второго жесткого диска (часто внешнего), магнитной ленты и всего остального. Резервная копия часто хранится в месте, физически отличном от данных, для которых выполняется резервное копирование, для защиты от сбоев "общего режима" (сбоев, когда одна основная причина влияет на несколько устройств, таких как скачок напряжения, вынимающий как оригинал, так и оригинал). в качестве резервной копии).

Кроме того, ваша схема имеет потенциально серьезную проблему.

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

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

Остановка программного обеспечения сервера базы данных является хорошим первым шагом, но это вовсе не гарантирует, что все кэши уровня ОС были сброшены в постоянное хранилище (с точки зрения ОС, работающей внутри ВМ).

PostgreSQL поставляется с утилитой pg_dump , которая будет выгружать базу данных в сценарий SQL, который может быть возвращен в PostgreSQL для восстановления базы данных. (Обязательно проверьте справочную страницу, чтобы все нужные параметры были правильными, и, как и во всех резервных копиях, протестируйте ее!) Это удобно, но не обязательно на 100%. В зависимости от ваших потребностей, это может быть достаточно хорошо.

Кроме того, вы можете остановить сервер PostgreSQL (это гарантирует отсутствие транзакций в полете) и скопировать его файлы данных в отдельное местоположение, которое обслуживается другим экземпляром PostgreSQL. Запустите оба и запустите pg_dump для второго экземпляра. После завершения дампа остановите второй экземпляр. Это более сложно, но фактически гарантирует, что вы получите внутренне согласованный дамп, не полагаясь на то, что формат файла данных PostgreSQL останется неизменным. Если база данных большая, возможно, следует скопировать большинство файлов во время работы PostgreSQL, а затем запустить что-то вроде rsync после остановки PostgreSQL для передачи дельты, чтобы сократить время простоя.

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