Бэкап во FreeBSD
Как и на любом другом, на сервере под управлением замечательной бесплатной операционной системы FreeBSD необходимо время от времени делать резервное сохранение информации. Ее объем, частоту и состав определяет администратор, исходя из функционала того или иного сервера. В данной заметке приведу пример того, как настроен бэкап на моем сервере под управлением FreeBSD 8.2-RELEASE, на котором установлены и настроены apache22, bind9, mysql-server, postfix и многое другое. |
Для выполнения backup будем пользоваться стандартными средствами FreeBSD. Самое главное из них – демон cron, служащий для запуска команд по расписанию. Чтобы не загромождать сам cron кучей строк, предлагаю создать отдельные исполняемые файлы, со списком необходимых нам команд. Для этого создадим в домашней директории пользователя root два файла backup_conf и backup_mysql. В первом файле мы напишем команды для сохранения всех конфигурационных файлов сервера, а во втором – необходимые для бэкапа базы данных mysql.
# touch /root/backup_conf # nano -w /rooot/backup_conf /usr/bin/tar -cjf /var/backups/server-etc_`date +%Y-%m-%d%n`.tar.bz2 /etc /usr/bin/tar -cjf /var/backups/server-usr-local-etc_`date +%Y-%m-%d%n`.tar.bz2 /usr/local/etc /usr/bin/tar -cj --exclude /var/named/var/run -f /var/backups/server-named_`date +%Y-%m-%d%n`.tar.bz2 /var/named /usr/bin/tar -cjf /var/backups/server-usr_local_www_`date +%Y-%m-%d%n`.tar.bz2 /usr/local/www # chmod +x /root/backup_conf
Небольшие пояснения для того, что мы сейчас проделали:
1. Мы создали в каталоге /root файл с именем backup_conf.
2. С помощью редактора nano мы занесли в этот файл команды, которые:
- архивирует все конфигурационные файлы из каталога /etc в файл вида
server-etc_2011-10-01.tar.bz2
в каталог /var/backups; - архивирует все конфигурационные файлы из каталога /usr/local/etc в файл вида
server-usr-local-etc_2011-10-01.tar.bz2
в каталог /var/backups; - архивирует все конфигурационные файлы и логи из каталога /var/named (в котором в chroot-окружении работает bind9), за исключением каталога /var/named/var/run, в файл вида
server-named_2011-10-01.tar.bz2
в каталог /var/backups; - архивирует файлы вашего web-сервера, расположенные по пути /usr/local/www в файл вида
server-usr_local_www_2011-10-01.tar.bz2
в каталог /var/backups.
3. Сделали наш файл /root/backup_conf исполняемым.
Замечание: замените server на hostname вашего сервера. Это полезно, если вы будете хранить в одном месте бэкапы нескольких FreeBSD серверов.
Теперь создадим в каталоге /root файл backup_mysql, куда внесем команды для бэкапирования интересующих нас баз mysql-server.
# touch /root/backup_mysql # chmod 0700 /root/backup_mysql # nano -w /root/backup_mysql /usr/local/bin/mysqldump -u root -password -h localhost -x -F phpmyadmin > /tmp/phpmyadmin.sql /usr/local/bin/mysqldump -u root -password -h localhost -x -F mysql > /tmp/mysql.sql /usr/bin/tar -cjf /var/backups/server-phpmyadmin_`date +%Y-%m-%d%n`.tar.bz2 /tmp/phpmyadmin.sql /usr/bin/tar -cjf /var/backups/server-mysql_`date +%Y-%m-%d%n`.tar.bz2 /tmp/mysql.sql /bin/rm /tmp/*.sql
Небольшие пояснения для того, что мы сейчас проделали:
1. Мы создали в каталоге /root файл с именем backup_mysql.
2. Сделали этот файл исполняемым и доступным только для root, так как он будет содержать пароль администратора в mysql (замените password на свой).
3. С помощью редактора nano мы занесли в этот файл команды, которые:
- делают дамп интересующих нас баз данных (самого mysql и phpmyadmin) в каталог /tmp;
- архивируют дампы баз данных mysql в файлы вида
server-mysql_2011-10-01.tar.bz2
в каталог /var/backups; - удаляет дампы баз данных mysql из каталога /tmp.
Нам осталось внести в cron созданные списки команд и настроить расписание их выполнения. Для этого:
# touch /root/cron # nano -w /root/cron MAILTO=user@domain.ru SHELL=/usr/local/bin/bash #minute hour mday month wday command 0 3 * * * /usr/local/bin/nmap -sP -e em0 --system-dns 192.168.0.0/16 | /usr/bin/grep -v MAC 30 0 * * * /root/backup_mysql 0 1 * * * /root/backup_conf 0 2 * * * /usr/bin/find /var/backups -type f -ctime -1 -execdir /usr/bin/ftp -u server@192.168.1.46:/ {} \; 5 0 * * * /usr/bin/find /var/virusmails -type f -ctime +31 -exec rm {} \;
Небольшие пояснения для того, что мы сейчас проделали:
1. Мы создали в каталоге /root файл с именем cron.
2. С помощью редактора nano мы занесли в этот файл строки, в которых:
- задается почтовый адрес, по которому будет слаться информация о выполнении команды по расписанию;
- указывается shell;
- ежедневно в 03:00 проводится сканирование всей внутренней сети на наличие поднятых хостов (чтобы потом драть пользователей за невыключенные на ночь компьютеры);
- ежедневно в 00:30 выполнить список команд, который мы занесли в файл /root/backup_mysql;
- ежедневно в 01:00 выполнить список команд, который мы занесли в файл /root/backup_conf;
- ежедневно в 02:00 по ftp передаем последние сделанные нами бэкапы на ftp-сервер по адресу 192.168.1.46, чтобы не хранить все яйца в одной корзине (как это делать, описывается мной тут);
- если у вас установлен postfix с прикрученным антиспамом amavisd-new, полезно иногда чистить каталог карантина /var/virusmails, что я и делаю последней строкой ежедневно в 00:05 (удаляются файлы старше 31 дня).
Вы можете добавить в файл /root/cron свои команды или списки команд, которые необходимо выполнять по расписанию.
Нам осталось выполнить команды:
# crontab /root/cron # crontab -l MAILTO=user@domain.ru SHELL=/usr/local/bin/bash #minute hour mday month wday command 0 3 * * * /usr/local/bin/nmap -sP -e em0 --system-dns 192.168.0.0/16 | /usr/bin/grep -v MAC 30 0 * * * /root/backup_mysql 0 1 * * * /root/backup_conf 0 2 * * * /usr/bin/find /var/backups -type f -ctime -1 -execdir /usr/bin/ftp -u server@192.168.1.46:/ {} \; 5 0 * * * /usr/bin/find /var/virusmails -type f -ctime +31 -exec rm {} \;
Первая команда заносит созданный нами список команд в cron. Вторая позволяет просмотреть этот список.
Статья не является универсальным лекарством, ее надо дополнять и перерабатывать “под себя”. Но если вы воспроизведете большинство из этих указаний для выполнения бэкапа, восстановление некоторой информации или всего (не дай Бог) сервера после его “падения”, пройдет гораздо быстрее и легче.
Удачи!
Не зачёт. Нет информации как потом восстановить в (не дай Бог) случае необходимости.