1. Пускане на WAL архивиране:
- в postgres.conf се добавя:
## пускане на копирането на WAL файловете
archive_mode = on
## команда за архивирането която ги изпраща в директорията на отдалечения сървър и им променя потребителя
archive_command = ‘test ! -f /tmp/pg_backup_in_progress && scp %p <remote user>@<rem serv IP>:<remote dir for WALs>/WALs/%f && ssh <remote user>@<rem serv IP> chown postgres <remote dir for WALs>/WALs/* </dev/null’
## през колко минути да се въртят ако не се напълни 16MB файл
archive_timeout = 60min
(след archive_mode = on трябва restart – за другите reload)
2. Скрипт за същинското бекъпване:
- примерен скрипт:
#!/bin/bash
opt=$1
## данни за връзката с сървъра за бекъп и за локалната директория на постгрес-а DATA="<postgres data dir>" RemDir="<remote dir for backup>" RemSrv="192.168.0.100" ## примерен бекъп сървър RemUsr="root" ## примерен потребител
## команда за копиране (синхронизиране) на фаиловете
if [ "$opt" = "debug" ]
then
Comm="/usr/bin/rsync -av --delete --exclude pg_xlog/ --exclude pg_log/"
archlog=" "
else
Comm="/usr/bin/rsync -a --delete --exclude pg_xlog/ --exclude pg_log/"
archlog=" > /dev/null"
fi
## при създаването на този файл спират да се копират WAL архивите от т.1 както е зададено от archive_command
touch /tmp/pg_backup_in_progress
## за стартиране на бекъпа е пуска функцията pg_start_backup()
## в постгрес сървъра независимо от коя база за да могат успешно
## да се копират файловете на базата
if [ "$opt" = "debug" ] ; then echo "$(date +%Y-%h-%d_%H.%M.%S) - start backup function on database" ; fi
label="hot_backup-$(date +%Y-%h-%d_%H.%M.%S)"
psql -U postgres postgres -c "select pg_start_backup('$label');"
## Преместваме директорията на WAL архивите в нов директория със съответната дата и
## се създава директорията отново. Операциите се извършват на отдалечения сървър
ssh $RemSrv mv $RemDir/WALs $RemDir/WALs-$(date +%Y-%h-%d_%H.%M.%S)
ssh $RemSrv mkdir $RemDir/WALs
## Същинската операция по копиране - използва се rsync за да се пести време ама може и друго
if [ "$opt" = "debug" ] ; then echo "$(date +%Y-%h-%d_%H.%M.%S) - START rsync on DATA dir" ; fi
$Comm $DATA $RemUsr@$RemSrv:$RemDir/data/
## спиране на бекъпа и визстановяване на нормалното действие на базата с функцията pg_stop_backup()
## пак няма значение към коя база се пуска
if [ "$opt" = "debug" ] ; then echo "$(date +%Y-%h-%d_%H.%M.%S) - stop backup function in database" ; fi
psql -U postgres postgres -c "select pg_stop_backup();"
## изтриване на временния файл за да може отново да се копират WAL архивите
rm /tmp/pg_backup_in_progress
## изчистване и подготовка на отдалечената директория за възстановяване
ssh $RemSrv mkdir -p $RemDir/data/pg_xlog/archive_status
ssh $RemSrv chown -R postgres $RemDir/data/pg_xlog/
ssh $RemSrv rm -f $RemDir/data/pg_xlog/archive_status/* $RemDir/data/pg_xlog/00* $RemDir/data/pg_log/*
- забележете, че се подразбира че има нагласена автоматична оторизация на съответния потребител с, който ще се
пуска скрипта и, че този потребител има права да пише в отдалечената папка
- след като се подготви скирипта се слага в някъде на системата (/usr/scripts/backup_the_postgresql.bash) и се тества
3. Периодично пускане на скрипта:
- просто се слага в cron-a за подходящо време
( 1 1 * * * /usr/scripts/backup_the_postgresql.bash debug 1> /var/log/pg_wal_backup.log 2>&1 )
4. Възстановяване:
- Вариант 1 (възстановяване на всички възможни транзакции):
- от горните точки се вижда, че при евентуално прецакване на базата данни ние оставаме с следните 2 неща:
папката с данни и конфигурации на постгрес
WAL архивите на транзакциите от момента на бекъпа до момента на прецакване - копираме папката с данни от бекъпа на мястото на старата (не преместване за да запазим и бекъпа все пак)
- копитаме WAL архивните файлове във времменна папка /tmp/WAL
- копираме WAL архивните файлове (пак същите) в папка pg_xlog
(в папката трябва да няма други фаилове – само под-директорията archive_status) - създаваме фаила recovery.conf в папката с данни – в него минимум трябва да има следния ред
( recovery_command = ‘cp /tmp/WAL/%f %p’) - папката с данни и всизки WAL файлове трябва да са притежание на потребителя на постгрес демона
за да могат да се прочетат при стартирането - стартиране на базата данни – ако всичко е наред при стартирането ще се прочетат всички транзакции от WAL фаиловете и ще се приложат на бекъпа за да се постигне същото състояние на базата данни както в момента на краша. След успешно стартиране файла recovery.conf ще бъде преименуван на recovery.done. Файла backup_label също ще бъде преименуван.
- ако има проблеми разгледайте логовете в pg_log
- Вариант 2 (възстановяване на състоянието в момента на пускането на бекъпа):
- копираме папката с данни от бекъпа на мястото на старата (не преместване за да запазим и бекъпа все пак)
- премахва се файла с име backup_label от директорията
- копитаме от WAL архивираните файлове този с разширение .backup. в директория pg_xlog/ и го преглеждаме за да видим кои е началния и крайния файл на архива ( редовете с тази информация започват съответно с START WAL и STOP WAL)
- копираме от WAL архивираните файлове от началния до крайния файл описани в .backup файла пак в директория pg_xlog/
- стартираме базата и изчакваме малко за да се прочетат WAL архивите и това е …
5. Това е от мен – за повече информация ето тук:
http://www.postgresql.org/docs/8.3/static/continuous-archiving.html