Proxmox Backup Server и restic: как выбрать уровни резервного копирования

Компания использует Proxmox VE: CRM и файловое хранилище работают в виртуальных машинах. Виртуальная машина, или ВМ, — отдельный сервер внутри физического хоста. После потери хоста может понадобиться вернуть всю ВМ; после удаления документа — только конкретный файл.

Proxmox Backup Server, далее PBS, связан с Proxmox VE и удобен для копий виртуальных машин. restic сохраняет выбранные файлы в поддерживаемом хранилище. У PBS тоже есть файловый клиент, поэтому выбор зависит от задачи, а не от жёсткого разделения возможностей.

• Вся машина. Помогает вернуть привычное окружение с операционной системой и приложением после потери сервера. Проверьте, что сохранены нужные диски и настройки ВМ.

• Данные приложения. База, вложения, настройки и ключи позволяют вернуть приложение на другую машину. Эти части должны соответствовать одному состоянию данных.

• Один файл. Отдельное восстановление документа полезно при ошибочном удалении. Нужна история, в которой можно найти подходящую копию до ошибки.

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

Начните с двух вопросов руководителю: сколько последних заявок допустимо потерять и сколько часов компания может работать без CRM. Первое определяет допустимый возраст восстановленных данных, второе — время возвращения сервиса. Эти величины обычно называют RPO и RTO.

Например, одна ночная копия не обеспечит потерю данных не больше часа. А обещание вернуть работу за час нужно проверить на реальном объёме. Расписание создания копий и время восстановления связаны с разными действиями; задайте оба требования отдельно.

Для часто меняющейся CRM может потребоваться частая копия базы, а для редких изменений инструкции — ежедневное сохранение. Если приложение отправляет письма или принимает оплаты, после восстановления понадобится сверка: возврат вчерашней базы не отменяет уже выполненные действия внешнего сервиса.

Режимы резервирования Proxmox VE отличаются временем простоя и способом сохранения данных. QEMU guest agent — служба внутри виртуальной машины — может помочь согласовать состояние файловой системы. Это не гарантирует, что любая база данных и её внешние связи сохранятся правильно.

Для CRM используйте предусмотренный приложением или базой способ создания копии. Согласуйте базу с вложениями и настройками; при необходимости на оговорённое время приостановите изменения. Произвольное копирование папки работающей PostgreSQL не заменяет поддерживаемое резервирование базы.

restic сохраняет подготовленные файлы, но не выбирает за вас правильный момент их создания. Если база ссылается на вложение, которое ещё не попало в копию, после восстановления запись останется без файла. Проверяйте эти связи отдельно.

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

История должна помогать и при ошибке, обнаруженной спустя неделю. Рассмотрите ежедневные, недельные и месячные точки восстановления — сохранённые состояния на разные даты. Их число зависит от объёма и требований компании. До включения удаления оцените место и нужную глубину истории.

• Сохранение истории. В PBS операция prune определяет, какие точки оставить. В restic похожую задачу решает forget. Сначала проверьте, какие копии переживут выбранное правило.

• Освобождение места. В PBS неиспользуемые данные убирает garbage collection; в restic — prune. Удаление точки и фактическое освобождение места могут быть разными этапами.

• Разделение доступа. Где это позволяет продукт и хранилище, ограничьте права задания создания копий. Возможность записать новую копию не должна без необходимости давать право удалить всю историю.

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

Вторая копия или синхронизация должны пережить потерю и компрометацию основного хоста. Продумайте отдельные права и хранение. Ключи расшифрования должны быть доступны аварийному ответственному: без них даже сохранённая зашифрованная копия может оказаться бесполезной.

Проверка целостности хранилища помогает обнаружить повреждённые данные. Она не подтверждает, что восстановленная CRM откроет клиентские записи. Даже успешный запуск операционной системы проверяет только часть задачи. Для приложения нужны известные данные и конкретные действия пользователя.

• Работа приложения. Откройте известного клиента, сделку и активность. Проверьте, что нужный сотрудник может выполнить разрешённое действие и не получает лишних прав.

• Связанные файлы. Откройте заранее выбранное вложение и сравните содержимое. Число файлов само по себе не подтверждает, что они относятся к нужным записям.

• Срок восстановления. Запишите начало и завершение этапов, дату возвращённых данных и ручные действия. Сравните их с согласованной потерей данных и временем простоя.

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

Для компании с Proxmox можно начать с PBS для нужных ВМ и отдельной согласованной копии критичного приложения в независимом хранилище. Добавляйте restic, если он упрощает сохранение файлов и перенос на другую систему. Если файловый клиент PBS подходит лучше, второй инструмент необязателен.

Proxmox распространяет открытые продукты, а подписка добавляет условия доступа к репозиторию обновлений и поддержки. restic тоже является открытым инструментом. В бюджет всё равно входят хранилище, обслуживание и время на проверку восстановления; назначьте ответственного за эти работы.

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