Как правильно создавать резервные копии ZODB-блобов? - PullRequest
7 голосов
/ 16 января 2009

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

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

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

Ответы [ 4 ]

13 голосов
/ 19 апреля 2010

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

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

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

3 голосов
/ 17 января 2009

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

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

2 голосов
/ 10 марта 2011

У меня есть скрипт, который в течение месяца копирует большие двоичные объекты с использованием жестких ссылок (так что у вас есть и исторические большие двоичные объекты, такие как 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)
1 голос
/ 24 марта 2009

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

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

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