Просмотр кода страницы Резервное копирование сервера (простой скрипт резервного копирования VPS сервера)

Резервное копирование данных в небольших проектах это наверное самая больная тема и если вы откроете любой фриланс-сайт, то увидите огромное количество заявок на восстановление данных разной степени изощренности, причем как показывает практика на 60% таких заявок можно или ставить крест сразу, или же они требуют несовместимых с предлагаемой оплатой трудозатрат. И конечно всего этого можно было избежать если правильно настроить резервное копирование.

Как я люблю повторять, вам мало настроить резервное копирование, вам надо потом из этого бэкапа еще и восстановить систему. В большинстве случаев с которыми я работал, мне предоставляли код проекта и дамп базы, причем код иногда был из гит-репозитария без статических и временных файлов необходимых для работы, а вместо SQL-дампа мне стабильно передают var-каталог с бинарными файлами mysql. Каждый раз когда мне передают адекватные архивы для восстановления это просто праздник и поэтому я решил поделиться некоторыми наработками которые я использую при администрировании клиентских проектов.

Первый метод который мы сейчас рассмотрим, предполагает небольшую "предполетную подготовку":

* Настраиваем авторизацию по ключам с сервера источника на сервер приемник
* Определяемся с построением файловой системы исходного сервера

== Создаем полный клон VPS-сервера ==

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

<syntaxhighlight lang="bash">
#!/bin/sh

mkdir /tmp/backup
mount /dev/sda1 /tmp/backup/

if [ -e '/tmp/backup/opt/backup/backup-me.dat' ]
then
   echo "Start backup"
   backup_date=`date +%d.%m.%Y`
   rsync -av --delete-after --numeric-ids /tmp/backup/ root@10.1.1.102:/opt/backup/city-freepbx/
fi

umount /tmp/backup/
</syntaxhighlight>

Как вы видите, мы монтируем структуру файловой системы в /tmp/backup/ и выполняем синхронизацию с удаленным сервером. Права суперпользователя на обоих серверах нужны для установки прав на каталоги, включая смену владельца и SUID-бит.

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

<syntaxhighlight lang="bash">
#!/bin/sh

mkdir /tmp/backup
mount /dev/sda1 /tmp/backup/

if [ -e '/tmp/backup/opt/backup/backup-me.dat' ]
then
   echo "Start backup"
   backup_date=`date +%d.%m.%Y`
   rsync -av --delete-after --numeric-ids /tmp/backup/ root@10.1.1.102:/opt/backup/city-freepbx/
   echo "tar -czvf /opt/backup/archive/$backup_date.tar.gz /opt/backup/city-freepbx/" | ssh root@10.1.1.102
fi

umount /tmp/backup/
</syntaxhighlight>
Сжатие производится на стороне принимающего данные сервера.

== Создание дампов баз данных ==
Копировать файловые части баз данных, это вообще самое глупое, что может прийти в голову, поэтому мы добавим создание дампа базы перед синхронизацией.

<syntaxhighlight lang="bash">
#!/bin/sh

mkdir /tmp/backup
mount /dev/sda1 /tmp/backup/

if [ -e '/tmp/backup/opt/backup/backup-me.dat' ]
then
   echo "Start backup"
   mysqldump --all-databases --all-tablespaces --add-drop-database > /opt/backup/database_dump.sql
   backup_date=`date +%d.%m.%Y`
   rsync -av --delete-after --numeric-ids /tmp/backup/ root@10.1.1.102:/opt/backup/city-freepbx/
   echo "tar -czvf /opt/backup/archive/$backup_date.tar.gz /opt/backup/city-freepbx/" | ssh root@10.1.1.102
   rm /opt/backup/database_dump.sql
fi

umount /tmp/backup/
</syntaxhighlight>
После того как вы восстановите сервер из полного бэкапа, вы сможете развернуть дамп базы. Обратите внимание, что помимо баз данных выгрузки дампа для обеспечения целостности копии требуют LDAP-каталоги, базы mongo, sqlite и т.п. все, что динамически изменяется.

Как вы понимаете только первая синхронизация займет много времени, а при последующих синхронизациях rsync будет передавать только измененные данные.

== Копирование с одновременным сжатием данных ==
Если же прав root-доступа на сервер приемник у вас нет, но создать полный дамп системы очень хочется, то вам ничего не мешает, сжимать данные в tar.gz-архив на стороне сервера источника и передавать на сервер приемних уже архив. Как вы знаете tar.gz-архив поддерживает сохранение правд доступа к файлам, владельцев и т.п. Единственным недостатком в этом случае является невозможность передавать разностные состояния и придется копировать все данные полностью.

<syntaxhighlight lang="bash">
#!/bin/sh

mkdir /tmp/backup
mount /dev/sda1 /tmp/backup/

if [ -e '/tmp/backup/backup-me.dat' ]
then
   echo "Start backup"
   backup_date=`date +%d.%m.%Y`
   su postgres -c pg_dumpall > /opt/backup/database_dump.sql
   tar zcvf - /tmp/backup | ssh backup-0001@backup.gita-dev.ru "cat > /home/backup-0001/cloud-apps.gita-dev.ru/$backup_date.tar.gz"
   rm /opt/backup/database_dump.sql
fi

umount /tmp/backup/
</syntaxhighlight>

[[Category:Debian]] [[Category:Ubuntu]] [[Category:Backup]]