Каков правильный способ резервного копирования объектов ZODB?

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

резервная копия.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)

Answer 4

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

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

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