Как правильно создавать резервные копии ZODB-блобов?

Я использую plone.app.blob для хранения больших объектов ZODB в каталоге blobstorage. Это уменьшает давление на размер Data.fs, но я не смог найти никаких советов по резервному копированию этих данных.

Я уже создаю резервную копию Data.fs, указав инструмент сетевого резервного копирования на каталог резервных копий repozo. Должен ли я просто указать этот инструмент в каталоге blobstorage для резервного копирования моих больших двоичных объектов?

Что делать, если база данных перепаковывается или капли добавляются и удаляются во время копирования? Есть ли в каталоге blobstorage файлы, которые нужно скопировать в определенном порядке?

Источник

4 ответа

Решение

Резервное копирование "blobstorage" сделает это. Нет необходимости в специальном заказе или что-либо еще, это очень просто.

Все операции в Plone полностью транзакционны, поэтому попадание в резервную копию в середине транзакции должно работать нормально. Вот почему вы можете делать живые резервные копии ZODB. Не зная, в какой файловой системе вы находитесь, я думаю, что она должна работать так, как задумано.

Источник

Должно быть безопасным делать резервное копирование Data.fs с последующим rsync из каталога blobstorage, если база данных не запаковывается во время выполнения этих двух операций.

Это связано с тем, что, по крайней мере, при использовании больших двоичных объектов с FileStorage, изменение большого двоичного объекта всегда приводит к созданию нового файла с именем на основе идентификатора объекта и идентификатора транзакции. Таким образом, если новые или обновленные большие двоичные объекты записываются после резервного копирования Data.fs, это не должно быть проблемой, так как файлы, на которые ссылается Data.fs, все еще должны присутствовать. Удаление большого двоичного объекта не приводит к удалению файла до тех пор, пока база данных не будет упакована, так что это тоже должно быть в порядке.

Выполнение резервного копирования в другом порядке или с упаковкой во время резервного копирования может привести к созданию резервной копии Data.fs, которая ссылается на большие двоичные объекты, которые не включены в резервную копию.

Источник

У меня есть сценарий, который в течение месяца копирует большие двоичные объекты, используя жесткие ссылки (так что у вас есть и исторические объекты больших двоичных объектов, такие как Data.fs):

backup.sh

#!/bin/sh

# per a fer un full : ./cron_nocturn.sh full

ZEO_FOLDER=/var/plone/ZEO

# Zeo port
ZEO_PORT = 8023

# Name of the DB
ZEO_DB = zodb1

BACKUP_FOLDER=/backup/plone

LOGBACKUP=/var/plone/ZEO/backup.log

BACKUPDIR=`date +%d`

echo "INICI BACKUP" >> $LOGBACKUP
echo `date` >> $LOGBACKUP

# Fem el packing

if [ "$1" = "full" ]; then
  $ZEO_FOLDER/bin/zeopack -S $ZEO_DB -p $ZEO_PORT -h 127.0.0.1


echo "   Comprovant folders"
#mirem si existeix el folder de backup
if ! [ -x $BACKUP_FOLDER/$ZEO_DB ]; then
   mkdir $BACKUP_FOLDER/$ZEO_DB
fi

#mirem si existeix el backup folder del dia
if ! [ -x $BACKUP_FOLDER/blobs/$BACKUPDIR/ ] ; then
   mkdir $BACKUP_FOLDER/blobs/$BACKUPDIR/
fi

echo "   Backup Data.fs"
# backup de Data.fs
if  [ "$1" = "full" ]; then
   echo "   Copiant Data.fs"
   $ZEO_FOLDER/bin/repozo -B -F -r $BACKUP_FOLDER/$ZEO_DB/ -f $ZEO_FOLDER/var/filestorage/Data_$ZEO_DB.fs
   echo "   Purgant backups antics"
   $ZEO_FOLDER/neteja.py -l $BACKUP_FOLDER/$ZEO_DB -k 2
else
   $ZEO_FOLDER/bin/repozo -B -r $BACKUP_FOLDER/$ZEO_DB/ -f $ZEO_FOLDER/var/filestorage/Data_$ZEO_DB.fs
fi

echo "   Copiant blobs"
# backup blobs
rm -rf $BACKUP_FOLDER/blobs/$BACKUPDIR
cd $BACKUP_FOLDER/current-blobs && find . -print | cpio -dplm $BACKUP_FOLDER/blobs/$BACKUPDIR
rsync --force --ignore-errors --delete --update -a $ZEO_FOLDER/var/blobs/ $BACKUP_FOLDER/current-blobs/


echo "FI BACKUP" >> $LOGBACKUP
echo `date` >> $LOGBACKUP

neteja.py

#!/usr/bin/python2.4

# neteja.py -l [directori_desti] -k [numero_fulls_a_mantenir]
# Script que neteja un directori amb backups i guarda nomes els ultims fulls que li especifiquis
# Es basa en la utilitzacio de collective.recipe.backup
# Author: Victor Fernandez de Alba <sneridagh@gmail.com>

import sys, getopt

sys.path[0:0] = [
  '/var/plone/genwebupcZEO/produccio/eggs/collective.recipe.backup-1.3-py2.4.egg',
  '/var/plone/genwebupcZEO/produccio/eggs/zc.buildout-1.4.2-py2.4.egg',
  '/var/plone/genwebupcZEO/produccio/eggs/zc.recipe.egg-1.2.2-py2.4.egg',
  '/var/plone/genwebupcZEO/produccio/eggs/setuptools-0.6c11-py2.4.egg',
  ]

import collective.recipe.backup.repozorunner

argv = sys.argv[1:]
try:
    opts, args = getopt.getopt(argv, "l:k:", ["location=", "keep="])
except getopt.GetoptError:
    print "neteja.py -l [directori_desti] -k [numero_fulls_a_mantenir]"
    sys.exit(2)

for opt, arg in opts:
    if opt in ("-l", "--location"):
        location = arg
    elif opt in ("-k", "--keep"):
        keep = arg

if len(opts)<2:
    print "neteja.py -l [directori_desti] -k [numero_fulls_a_mantenir]"
    sys.exit(2)

collective.recipe.backup.repozorunner.cleanup(location, keep)
Источник

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

В этом случае (с BlobStorage в сочетании с FileStorage) я должен указать на обычный совет резервного копирования:

  • переводить базу данных в автономный режим при копировании файловой системы
  • использовать инструменты моментальных снимков, такие как LVM, чтобы заморозить диск в заданной точке
  • сделать транзакционный экспорт (не осуществимо на практике)
Источник
Другие вопросы по тегам