Резервное копирование — различия между версиями
(→Если нет 7-Zip) |
(→Результат) |
||
| (не показано 11 промежуточных версии этого же участника) | |||
| Строка 4: | Строка 4: | ||
<pre> | <pre> | ||
| + | # подготовка (делается один раз) | ||
sudo bash | sudo bash | ||
mkdir -p /home/db-backups | mkdir -p /home/db-backups | ||
| Строка 14: | Строка 15: | ||
</pre> | </pre> | ||
| − | Занесение в расписание: откройте файл /etc/crontab | + | Проверьте, что в <code>/home/db-backups/</code> создался архив и он распаковывается. |
| + | |||
| + | Занесение в расписание: откройте файл | ||
| + | <pre>/etc/crontab</pre> | ||
и допишите туда: | и допишите туда: | ||
<pre> | <pre> | ||
| Строка 20: | Строка 24: | ||
# SP Database Backup | # SP Database Backup | ||
# ---------------------------------------- | # ---------------------------------------- | ||
| − | 0 0 * * * root /usr/bin/7z a -mx5 /home/db-backups/gdb-$(date +\%F).7z /opt/xxi/data/ | + | 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 + | + | 0 0 * * * root /usr/bin/find /home/db-backups -name "*.7z" -mtime +60 -exec rm -f {} \; |
</pre> | </pre> | ||
| Строка 52: | Строка 56: | ||
<pre> | <pre> | ||
| − | 0 0 * * * root /usr/bin/find /home/db-backups -name "*.gz" -mtime + | + | 0 0 * * * root /usr/bin/find /home/db-backups -name "*.gz" -mtime +30 -exec rm -f {} \; |
</pre> | </pre> | ||
| Строка 59: | Строка 63: | ||
== Результат == | == Результат == | ||
| − | Каждые сутки в полночь будут создаваться резервные копии баз портала. Они будут складываться в папку /home/db-backups, доступную только для пользователю root. Копии старше | + | Каждые сутки в полночь будут создаваться резервные копии баз портала. Они будут складываться в папку /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 | ||
Текущая версия на 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 мегабайт.
