Резервное копирование

Введение:

Данная статья скорее документирование конкретно взятой ситуации (ОС+железо), чем руководство к действию.

Итак, надо настроить резервное копирование четырех серверов веб-приложений (Ubuntu) и двух серверов баз данных PostgresSQL (Ubuntu). Все 6 серверов — это виртуалки на ESXi и все они еженощно бэкапируются при помощи VeeamBackup & Replication. Но для дополнительного удобства было принято решение отдельно копировать и хранить в доступном месте файлы веб-приложений и дампы баз данных.

Подготовка окружения:

Резервные копии будут создаваться локально, а затем копироваться во внешнее хранилище NAS QNAP. Ежедневные (daily) резервные копии будут храниться только 7 дней (в двух экземплярах локально и на сетевом хранилище), а еженедельные (weekly) — более длительное время (пока не будут удалены вручную), но только на сетевом хранилище (локальные weekly копии будут удалены по истечении недели). 

На сетевом хранилище необходимо включить протокол rsync:

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

А затем создать общую папку и в настройках прав доступа, активировать доступ по протоколу nfs:

Для возможности работы с nfs на сервере необходимо установить пакет nfs-common:

sudo apt install nfs-common

В случае необходимости примонтировать сетевой диск можно командой:

sudo mount 192.168.9.201:/BackupVol2 /mnt/BackupVol2/

предварительно создав соответствующую точку монтирования:

sudo mkdir /mnt/BackupVol2

Подготовка закончена, можно переходить к созданию резервных копий:

Резервное копирование веб-серверов (/var/www):

Локальные резервные копии располагаются по следующим путям:

/opt/backups/'hostname'/daily/ — для ежедневных резервных копий

/opt/backups/'hostname'/weekly/ — для еженедельных резервных копий

Перед созданием новой резервной копии, файлы старше 7 дней удаляются. Резервные копии дублируются на внешнее хранилище по протоколу rsync. Из папки daily файлы копируются с ключом --delete, что позволяет удалять файлы на внешнем хранилище, если они уже удалены локально. Еженедельные же копии хранятся на внешнем хранилище, пока не будут удалены вручную, а локально удаляются автоматически по истечении недели (копируются rsync’ом без ключа --delete).

Для работы нижеприведенных скриптов понадобятся дополнительные пакеты: rsync и sshpass.

Исполняемым скрипт делается командой:

chmod +x /путь_к_файлу/сам_файл.sh

Ежедневный скрипт запускается из home директории записью в файле crontab:

50 3 * * * root /home/имя_пользователя/tardaily.sh — ежедневно в 3ч. 50мин.

Скрипт tardaily.sh:

#!/bin/bash

FILE_TIME_STAMP=`date '+%Y_%m_%d_%H-%M'`
BACKUP_HOST_NAME=`hostname`
BACKUP_FILE_EXT=".tgz"
BACKUP_FILE=$BACKUP_HOST_NAME$FILE_TIME_STAMP$BACKUP_FILE_EXT
#mkdir /opt/backups/$BACKUP_HOST_NAME/daily
find /opt/backups/$BACKUP_HOST_NAME/daily -mtime +7 -exec rm {} \;
/bin/tar cvpzf /opt/backups/$BACKUP_HOST_NAME/daily/$BACKUP_FILE /var/www/
sshpass -p 'пароль' rsync -avh --delete /opt/backups/$BACKUP_HOST_NAME/daily rsync://имя_пользователя@192.168.9.201:/BackupVol2/$BACKUP_HOST_NAME/

Еженедельный скрипт запускается из директории /etc/cron.weekly соответствующей записью в файле crontab.

Скрипт tarweekly.sh:

#!/bin/bash

FILE_TIME_STAMP=`date '+%Y_%m_%d_%H-%M'`
BACKUP_HOST_NAME=`hostname`
BACKUP_FILE_EXT=".tgz"
BACKUP_FILE=$BACKUP_HOST_NAME$FILE_TIME_STAMP$BACKUP_FILE_EXT
#mkdir /opt/backups/$BACKUP_HOST_NAME/weekly
find /opt/backups/$BACKUP_HOST_NAME/weekly -mtime +7 -exec rm {} \;
/bin/tar cvpzf /opt/backups/$BACKUP_HOST_NAME/weekly/$BACKUP_FILE /var/www/
sshpass -p 'пароль' rsync -avh /opt/backups/$BACKUP_HOST_NAME/weekly rsync://имя_пользователя@192.168.9.201:/BackupVol2/$BACKUP_HOST_NAME/

С веб-серверами закончили, переходим к базам данных.

Резервное копирование PostgresSQL:

Все будет проходить по такому же сценарию, как и с веб-серверами, только вместо tar, будет использоваться pgdump и gzip. Pgdump устанавливается вместе с Postgesql, поэтому из дополнительных компонентов останется добавить только rsync, sshpass и nfs-common.

В процессе тестирования выявились какие-то не понятные проблемы в работе rsync’а по своему собственному протоколу — он зависал при копировании файлов, размером около 500Мб на сетевое хранилище. Однако, при копирование в ту же директорию, но уже подключенную, как сетевой диск по nfs, такая проблема не возникала. Было решено так и оставить — монтировать к серверам баз данных сетевое хранилище по nfs и копировать rsync’ом без применения его протокола.

Монтирование nfs диска через fstab:

В файл /etc/fstab добавляем подобную запись:

192.168.9.201:/BackupVol2 /mnt/BackupVol2 nfs

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

Скрипт pgdaily.sh:

#!/bin/bash

DATABASE='имя_базы_данных'
BACKUP_HOST_NAME='hostname'
#mkdir /opt/backups/$BACKUP_HOST_NAME/daily
pathB=/opt/backups/$BACKUP_HOST_NAME/daily
find $pathB -mtime +7 -exec rm {} \;
sudo -u postgres pg_dump $DATABASE | gzip > $pathB/pgsql32_$(date "+%Y-%m-%d_%H-%M").sql.gz
rsync -avh --delete /opt/backups/$BACKUP_HOST_NAME/daily /mnt/BackupVol2/$BACKUP_HOST_NAME/

Скрипт pgweekly.sh:

#!/bin/bash

DATABASE='имя_базы_данных'
BACKUP_HOST_NAME='hostname'
#mkdir /opt/backups/$BACKUP_HOST_NAME/weekly
pathB=/opt/backups/$BACKUP_HOST_NAME/weekly
find $pathB -mtime +7 -exec rm {} \;
sudo -u postgres pg_dump $DATABASE | gzip > $pathB/pgsql32_$(date "+%Y-%m-%d_%H-%M").sql.gz
rsync -avh /opt/backups/$BACKUP_HOST_NAME/weekly /mnt/BackupVol2/$BACKUP_HOST_NAME/

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

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

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