Резервное копирование — различия между версиями

Текущая версия на 18:44, 12 октября 2016

Организация ежедневного резервного копирования баз данных со сжатием и чисткой копий старше 30 дней.

Полный общий рецепт, он же рецепт для Ubuntu

# подготовка (делается один раз)
sudo bash
mkdir -p /home/db-backups
chmod 755 /home/db-backups
chown root:root /home/db-backups
apt-get -y --force-yes install p7zip-full

# разовое выполнение резервного копирования делается так:
/usr/bin/7z a -mx5 /home/db-backups/gdb-$(date +%F).7z /opt/xxi/data/

Проверьте, что в /home/db-backups/ создался архив и он распаковывается.

Занесение в расписание: откройте файл

/etc/crontab

и допишите туда:

# ----------------------------------------
# SP Database Backup
# ----------------------------------------
0 0 * * * root  /usr/bin/7z a -mx5 /home/db-backups/gdb-$(date +\%F).7z /opt/xxi/data/ > /dev/null
0 0 * * * root  /usr/bin/find /home/db-backups -name "*.7z"  -mtime +60 -exec rm -f {} \;

Отличия в Mandriva

Отличается командой установки 7-Zip:

urpmi p7zip

и именем исполняемого файла 7-Zip: не 7z, а 7za.

Отличие в ALT Linux

Отличается от Ubuntu командой установки 7-Zip:

apt-get install p7zip

Если нет 7-Zip

Можете использовать tar:

tar -czf /home/db-backups/gdb-$(date +\%F).tar.gz /opt/xxi/data/

Команда в crontab для очистки архивов старше 30 дней будет выглядеть иначе:

0 0 * * * root  /usr/bin/find /home/db-backups -name "*.gz" -mtime +30 -exec rm -f {} \;

Суть изменения в том, что удаляются не файлы *.7z, а *.gz

Результат

Каждые сутки в полночь будут создаваться резервные копии баз портала. Они будут складываться в папку /home/db-backups, доступную только для пользователю root. Копии старше 60 дней будут удаляться автоматически.

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

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

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

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

Точные данные о размере архивов дать невозможно, всё сильно зависит от количества информации в базе. Примеры:

• ежедневное резервирование большой базы (одного из самых первых пользователей портала, данных там за несколько лет) в количестве 30 дней занимает около 700 мегабайт.
• ежедневное резервирование небольшой базы в количестве 30 дней занимает около 160 мегабайт.

Как копировать вообще всё, а не только базу

См. рецепт: http://wiki.spcms.ru/Перенос_Школьного_портала_на_другой_сервер#.D0.92.D1.81.D1.91_.D0.B1.D0.B5.D0.B7_.D0.BA.D0.BE.D0.BC.D0.BC.D0.B5.D0.BD.D1.82.D0.B0.D1.80.D0.B8.D0.B5.D0.B2_.D0.B4.D0.BB.D1.8F_.D0.BE.D0.BF.D1.8B.D1.82.D0.BD.D1.8B.D1.85