You are here: Foswiki>Gnumed Web>GmManualDatabaseBackupRestoreRu (29 Jan 2013, IvanLykov)EditAttach

Процедуры резервного копирования и восстановления базы данных

GNUmed принимает все меры для защиты медицинских данных в процессе обновления и эксплуатации:

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

Однако, беда поражает, когда меньше всего ожидаема и имеется целый мир проблем, с которыми GNUmed не может сделать ничего. Существует несколько правил разумного поведения:

  • используйте RAID для дисков базы данных
  • используйте мониторинг S.M.A.R.T. дисков базы данных
  • реплицируйте на резервной машине
  • предусмотрите клонирование физической машины на виртуальную (например, с конвертером VMware)
  • пользуйтесь резервными копиями
  • автоматизируйте создание резервных копий
  • держите несколько поколений резервных копий
  • храните дубликаты резервных копий и на- и вне
  • Проверяйте резервные копии!
  • Тестируйте процедуры восстановления!

Если вы последуете советам выше, вы сделаете совсем немного, чтобы быть на безопасной стороне. Руководство PostgreSQL имеет отличные главы по резервному копированию и восстановлению, а также по репликации и совместимости. Не забудьте прочитать его.

GNUmed предоставляет некоторые сценарии и файлы настройки под *nix, готовые к интеграции с cron/anacron. Их можно найти:

  • в релизах сервера, доступных здесь, где сценарии находятся на том же уровне, как каталог bootstrap и файлы .conf, находящиеся в подкаталоге /etc/gnumed, на том же уровне

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

Настройка файлов конфигурации (.conf)

Расположение и имена файлов .conf должны быть правильно отражены в зависимых файлах сценариев. По умолчанию, сценарии ожидают найти файлы .conf в директории /etc/gnumed с именами gnumed-backup.conf и gnumed-restore.conf.

Кроме того, каждый файл .conf содержит ряд опций, которые почти всегда должны быть изменены. К ним относятся
  • некоторое подходящее имя, представляющее практику, которое станет INSTANCE_OWNER
  • где, в конечном итоге, хранится резервная копия, по умолчанию являющееся BACKUP_DIR="${HOME}/.gnumed/backup/" и которое, если не изменено, приведет к записи резервной копии в каталог, принадлежащий root. Под Mac OS 10.x оно будет /var/root/.gnumed/backup
  • чья база данных для резервного копирования, например GM_DATABASE="gnumed_v15"
  • пользователь/группа, чья резервная копия, в конечном счете, принадлежит BACKUP_OWNER="$USER:$USER"
  • дополнительные опции, например, для offsiting и использования gnotary

Настройка файлов скриптов (.sh)

Сценарии gm-backup_database.sh и gm-restore_database.sh могут быть запущены без изменений, за исключением дополнительных ограничений Mac OS.

Обратите также внимание, что при выполнении резервного копирования или восстановлении вручную – когда вы еще не настроили pg_hba.conf для доступа root к базе данных GNUmed, как "gm-dbo", и когда вы не создали файл .pgpass – сработает вот это

  • sudo -i to root
  • cd в соответствующую директорию, где находятся сценарии shell
  • выполните сценарий sh gm-backup_database.sh
  • предоставьте пароль для пользователя базы данных postgres (дважды) и пароль для gm-dbo (дважды)
  • проверьте, любая ли база данных, новее, чем база данных, указанная в вашем файле conf, должна быть, возможно, той, которой на самом деле нужно резервное копирование. Это будет зависеть от того, имели ли вы после обновления рабочую базу данных, или более новые версии просто для испытания.

Ограничения Mac OS:

  • воизбежание неприятностей в Mac OS, для поддержки командной строки (или сценария shell) su -c, необходимо под Mac OS закомментировать с # 'sanity check' (проверка вменяемости - пер.) скрипта резервного копирования, который под linux может проверить, существует ли база данных.
  • так как Mac OS не поддерживает -W (проверку), пользователи Mac должны настроить VERIFY_TAR на пустую строку "" в gnumed-backup.conf, который затем сделает то, что нужно

Архивные электронные сообщения:

Дополнительную загадочную и редко необходимую информацию можно найти на этой странице
Topic revision: 29 Jan 2013, IvanLykov
 
Download.png
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark