Резервное копирование Plone

Мой вольный перевод страницы Backing up your Plone deployment (https://docs.plone.org/manage/deploying/backup.html)
Tags:

2019-05-15

Backing up your Plone deployment

Стратегии резервного копирования действующих Plone установок.

Эта инструкция расскажет что копировать, как копировать и как безопасно восстановить.

Введение

Ключевые правила резервного копирования работающей системы возможно следующие:

  • Бэкапируй всё
  • Делай несколько версий бэкапа
  • Тестируй бэкапы на предмет восстановления

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

Ваш buildout и его кэши уже забэкапированы, и вы протестировали процесс восстановления.

Вам осталось поразмышлять об адекватном бэкапе и восстановлении базы данных Plone.

Объекты в движении

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

Объекты в движении имеют тенденцию оставаться в движении. Объекты, которые движутся, сложно или невозможно аккуратно бэкапить.

Расшифровка: Plone является долгоживущим процессом, который постоянно изменяет содержимое базы данных. Наибольший из этих файлов, это Data.fs, который содержит всё, кроме “Двоичных Больших Объектов” Binary Large OBjects (BLOBs), и этот файл постоянно открыт для записи. Хранилище BLOB’ов — это директория с множеством вложенных папок и со сложной файловая иерархией, которая постоянно изменяется и должна быть синхронизирована с Filestorage.

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

Где мои данные

Директория с вашим экземпляром Plone будет содержать папку ./var (это в той же папке, где лежит и buildout.cfg), которая содержит часто меняющиеся файлы данных для Plone. Тем не менее, многое из того, что есть в ./var, не является вашей реальной базой данных контента. Скорее, это журнал, идентификатор процесса и файлы сокетов.(?)

Директории, которые на самом деле содержат данные контента:

Filestorage

./var/filestorage:

Здесь содержится файловое хранилище Zope Object Database. Если у вас нет нескольких хранилищ или если вы не меняли имя, то ключевой файл — Data.fs. Обычно это большой файл, содержащий всё, кроме BLOB’ов.

Другие файлы в Filestorage с такими расширениями, как .index, .lock, .old, .tmp являются эфемерными и будут воссозданы Zope в случае их отсутствия.

Blobstorage

./var/blobstorage:

Этот каталог содержит глубоко вложенную иерархию папок, которые, в свою очередь, содержат большие двоичные объекты (BLOB’ы) вашей базы данных: PDF-файлы, файлы изображений, файлы автоматизации делопроизводства и тому подобное.

Главное, что нужно знать о Filestorage и Blobstorage, это то, что они поддерживаются синхронно. В Filestorage есть ссылки на BLOB-объекты в Blobstorage. Если два хранилища не синхронизированы, вы получите ошибки.

collective.recipe.backup

collective.recipe.backup — это отлично обслуживаемый с отличной поддержкой “recipe”, решающий проблему “объекта в движении” для базы данных Plone. Он делает лёгким и копирование и восстановление базы данных. “Recipe” представляет собой сложную оболочку вокруг repozo — инструмента бэкапа базы данных Zope, и rsync — обычного инструмента для синхронизации файлов.

Большое спасибо Reinout van Rees, Maurits van Rees и всем помощникам сообщества за создание и поддержку community.recipe.backup.

Если вы используете любой из установочных комплектов Plone, в вашем варианте установки уже входит “collective.recipe.backup”. Если нет, вы всегда можете включить его в сборку, добавив ‘backup’ часть:

[buildout]
parts =
    ...
    backup
    ...

[backup]
recipe = collective.recipe.backup

Есть несколько полезных опций настройки этого “recipe”. Все они описаны на странице PyPI. Возможно, наиболее полезным является опция ’location’, которая указывает место хранения файлов резервных копий:

[backup]
recipe = collective.recipe.backup
location = /path/to/reliably/attached/storage/filestorage
blobbackuplocation =  /path/to/reliably/attached/storage/blobstorage

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

Работа

После того, как вы запустите buildout, в вашей сборке Plone появятся скрипты bin/backup и bin/restore. Поскольку все параметры задаются через buildout, с помощью малого количества опций, то работа, как правило, заключается в простом запуске этих скриптов. Для bin/restore, в случае наличия нескольких резервных копий, может указываться дата и время любого из сохранённых бэкапов. Смотрите документацию для дополнительной информации.

Бэкап может выполняться без остановки Plone. Но операция восстановления требует остановки Plone, а после завершения восстановления повторного запуска Plone.

bin/backup обычно добавляется в cron для регулярного выполнения бэкапов. Убедитесь, что вы протестировали бэкап и восстановление из бэкапа, прежде чем полагаться на него.

Инкрементные бэкапы

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

Если включено инкрементное резервное копирование, выполнение операции упаковки базы данных автоматически приведёт к тому, что следующая резервная копия будет полной резервной копией.

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