DSPACE и Бэкап

Опубликовано 27 октября, 2013 автором IdeaFix

Бэкап — вещь нужная, сложная и не всегда с первого раза прозрачная и понятная. Обычно, вариантов бэкапа может быть более одного, бэкап частично пересекается с резервированием, может служить механизмом переноса контента или сервиса… в общем, бэкап в целом — это очень широко, а бэкап DSPACE в частности — очень широко тоже.

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

1. Бэкап виртуальной машины или контейнера целиком.

Под данным видом бэкапа я понимаю создание полной копии виртуальной машины, контейнера, либо жесткого диска выделенного сервера. У данного метода есть как откровенные плюсы и минусы, так и некоторые спорные моменты, которые стоит иметь в виду, итак

Плюсы:

  • Полный бэкап и операционной среды, и сервиса и контента и настроек и статистики и пр.
  • Возможность использования дампа для миграции сервиса, фонда и пр.

Минусы:

  • Приличный размер дампа (если суммарный размер контента составляет 50GB, то получить дамп контейнера в 70-80GB легко)
  • Значительное время создания, восстановления и переноса бэкапа в связи с размерами
  • Нагрузка на IT инфраструктуру (сеть, сторадж, процессорное время и пр.) для создания, хранения и передачи бэкапа

NB!:

  • СУБД и соответственно база данных могут быть на другом логическом/физическом хосте и их придется бэкапить отдельно.
  • Система DNS/NAT может быть на другом логическом/физическом хосте и как следствие полностью прозрачные миграции/восстановление могут не получиться
  • ФронтЭнд web сервер (apache httpd + mod jk, nginx и пр.) может располагаться на другом логическом/физическом хосте что опять же сузит возможность миграции и добавит «дополнительных» бэкапов
  • Не всегда есть доступ к гипервизору для полного бэкапа, не всегда есть на нем место, не всегда есть административный ресурс для того, чтобы заставить сделать что-то того, у кого есть доступ к гипервизору…

Вывод

Если архив не большой, расположен на выделенном сервере с физическим доступом или в виртуальной машине, если в плане организации сетевого доступа и СУБД он (сервис) самодостаточен, то полный бэкап время от времени делать нужно. Например, перед серьезными пополнениями фонда, обновлением компонентов сервиса, операционной среды или аппаратного обеспечения. Если же архив большой и завязан на «внешние» элементы IT инфраструктуры, полный бэкап нужно делать в тех же ситуациях, но с оглядкой на объём и «внешние» компоненты.

2. Бэкап сервиса целиком.

Под данным видом бэкапа я понимаю бэкап всей RUNTIME обвязки, сервиса, контента и базы данных. Если под сервис выделен отдельный сервер, виртуальный или физический, то всё относительно просто, база бэкапится в файл, директория dspace, директории runtime обвязки и пр. бэкапятся простым копированием, системные переменные, задачи по расписанию, настройки сервисов и пр. бэкапятся соответствующими средствами, всё это пакуется в один архив и…

Плюсы:

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

Минусы:

  • Приличный размер дампа (Незначительно превышает размер контента)
  • Значительное время создания, восстановления и переноса бэкапа в связи с размерами, возможно, потребуется остановка сервиса
  • Нагрузка на IT инфраструктуру (сеть, сторадж, процессорное время и пр.) для создания, хранения и передачи бэкапа

NB!:

  • Достаточно «топорный» метод, в духе UNIX way

Вывод

Такой метод бэкапа удобен когда сервис живет на большом сервере (в chroot или контейнере), процессорное время и диск не ограничены, скорость всего этого дела внушительная, а никаких особых инструментов помимо того что есть на сервере (sh, tar, copy, pg_dump) нет, равно как нет и доступа к управлению контейнером.

3. Бэкап контента посредством макроса EXPORT.

Бэкап встроенным инструментом «export». Суть его проста. Имея список всех коллекций можно последовательно выполнить следующую команду:

[DSPACE]\bin\dspace export -t COLLECTION -i HANDLEPREFIX/HANDLE -n 1 -d [\BACKUP]\HANDLE

для всех коллекций. Аналогично можно архивировать/экспортировать отдельные документы, но не разделы. Для того, чтобы не потерять структуру разделов, придется дополнительно сохранять дамп базы и возможно метаданные. Последнее можно сделать так:

[DSPACE]\bin\dspace metadata-export -f [BACKUP]\metadata.bak

Пример cmd файла бэкапа небольшого архива:

set now=%TIME:~0,-3%
set now=%now::=%
set now=%now: =0%
set now=%DATE:~-4%.%DATE:~3,2%.%DATE:~0,2%_%now%
mkdir c:\BACKUP\%now% && c:\dspace\bin\dspace metadata-export -f c:\BACKUP\%now%\%now%_metadata.bak && mkdir c:\BACKUP\%now%\6 && c:\DSPACE\bin\dspace export -t COLLECTION -i 123456789/6 -n 1 -d c:\BACKUP\%now%\6 && mkdir c:\BACKUP\%now%\12 && c:\DSPACE\bin\dspace export -t COLLECTION -i 123456789/12 -n 1 -d c:\BACKUP\%now%\12

Так же мной была обнаружена реализация этого метода на PHP. После доработки напильником получалось что-то такое:

<?php
$today = date("Y.m.d_H.i.s");
$arr = array(
1,
2,
7,
15,
);

mkdir ("c:/backup/$today");

$cmd0 = "C:\RUNTIME\POSTGRE\bin\pg_dump.exe -i -h 127.0.0.1 -p 5432 -U dspace -F c -b -v -f c:/backup/$today/bdbackup dspace";
exec ($cmd0);

$cmd1 = "dspace metadata-export -f c:/backup/$today/metadata";
exec ($cmd1);

$z = 100;
foreach ($arr AS $coll) {
  mkdir ("c:/backup/$today/$coll");
  $cmd2 = "dspace export -t COLLECTION -i 10995/$coll -d c:/backup/$today/$coll -m -n $z";
  exec ($cmd2);

  $z += 100;
}

Источник здесь.

Плюсы:

  • Быстро, паралельно с работой сервиса
  • Возможен частичный бэкап отдельных коллекций/документов

Минусы:

  • При импорте и экспорте не сохраняется bitstream order, что приводит к «битым» ссылкам на файлы
  • При импорте и экспорте могут «потеряться» языковые значения полей, появиться дубли полей и пр.
  • Не бэкапится структура разделов/коллекций

NB!:

  • Достаточно «топорный» метод, в духе UNIX way
  • Для регулярного бэкапа и рестора подходит слабо

Вывод

Такой метод бэкапа удобен… даже не знаю когда. Когда нужно выгрузить фонд и загрузить его куда-то заново. Т.е. в случае миграции/переезда. Сущности бэкапятся в SAF, что упрощает их пакетное редактирование. Учетные записи пользователей, администраторов, группы, права и пр. не экспортируются

4. Бэкап контента посредством макроса PACKAGER.

Бэкап встроенным инструментом «packager». Суть его проста. Имея HANDLE Prefix можно выполнив следующую команду:

[DSPACE]\bin\dspace packager -d -a -u -t AIP -e YOUREMAIL -i HANDLEPREFIX/0 [BACKUP]\YOURNAME.zip

получить полный бэкап фонда с сохранением структуры и метаданных.

Пример cmd файла бэкапа небольшого архива:

set now=%TIME:~0,-3%
set now=%now::=%
set now=%now: =0%
set now=%DATE:~-4%.%DATE:~3,2%.%DATE:~0,2%_%now%

mkdir c:\BACKUP\%now% && c:\dspace\bin\dspace packager -d -a -u -t AIP -e ideafix@ideafix.name -i 123456789/0 c:\backup\%now%\elar-usfeu.zip

Плюсы:

  • Быстро, паралельно с работой сервиса
  • Возможен частичный бэкап отдельных коллекций/документов
  • Бэкап метаданных и структуры архива

Минусы:

  • Бэкап представляет из себя множество (количество равно сумме всех архивируемых хэндлов) zip архивов. Сжатие умеренное, как следствие, особого выигрыша места нет, а процессорное время тратится.

NB!:

  • Для регулярного бэкапа конента подходит идеально

Вывод

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

Общий вывод

На мой взгляд целесообразно совмещать первый и четвертый виды бэкапа. Первый перед серьезными изменениями/обновлениями сервиса, операционной среды, аппаратной составляющей. Второй — перед серьезными изменениями/обновлениями контента или метаданных, да и просто регулярно.

Запись опубликована в рубрике Библиотека с метками , . Добавьте в закладки постоянную ссылку.

5 комментариев на «DSPACE и Бэкап»

  1. Уведомление: Обновление существующей инсталляции DSpace до версии 5.3 на платформе Windows | IdeaFix

  2. Сергей говорит:
    20 октября, 2017 в 18:01

    Написано как делать бэкапы, но нет инструкций как их восстанавливать ))
    Так задумано?

    Ответить
    • IdeaFix говорит:
      20 октября, 2017 в 20:30

      Так вроде логично всё…
      1. Бэкап виртуальной машины или контейнера разворачивается средствами гипервизора, или копипастом.
      2. Бэкап сервиса разворачивается копипастом или разворотом снепшота
      3. макросы export и metadata-export имеют зеркальные import и metadata-import
      4. ну а dspace packager help — это святое…

      Всё-таки это не «коробочная шпаргалка», а «мысли вслух», переосмысление которых обязательно, а прямое копирование не желательно.

      Ответить
  3. Allenrush говорит:
    28 декабря, 2017 в 13:08

    Здравствуйте, IdeaFix! Подскажите, пожалуйста, как можно перенести весь фонд целиком с сохранением структуры с одного dspace (на ubuntu 7) на другой (windows server 2008)?

    Ответить

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *