Системы резервного копирования
### Наиболее респостраненные ошибки при организации резервного копировани баз данных ###
http://citrin.ru/backup.html
Эти принципы применимы не только к базам данных, но и к резервному копированию в целом.
Отрывок из книги PostgreSQL. Руководство разработчика и администратора. Гешвинде, Шениг
В основном при работе с сервером баз данных допускают шесть ошибок:
- Резевные копии вообще отсутствуют.
Не стоит и говорить, что это наверняка приведет к возниконовнию серьезных проблем.
- Резервные копии созднаны, но процесс восстановления никогда не тестировался .
Возможно это одна из наиболее серьезных ошибок, допускаемых при работе с резервными копиями. Администратор создает резервные копии и уверен, что данные защищены от любых неожиданностей. Однако, если неизвестно, как работает восстановление, в аварийных ситуациях можно столкнуться с серьезными проблемами. Если восстановление никогда раньше не проверялось, администратор чувствует себя неуверенно в процессе восстановления, что, в свою очередь, приводит к дополнительным потерям времени и ошибкам. Убедитесь, что вы достаточно хорошо знаете, как восстановливать данные из резервоных копий. Это очень важный аспект, о котором большинство пользователей и администраторов попросту забывает.
- Вы создаете резервные копии, но никто кроме вас о них не знает.
Вообще говоря, машины надежнее людей. Это следует учитывать при разработке систем баз данных и стратегий резервного копирования. Во многих организациях, с которыми нам приходилось иметь дело в течение нескольких последних лет, мы наблюдали весьма опасную тенденцию: человек, который отвечал за резервное копирование или за всю информационную систему, был единственным распологающим всей информацией о состоянии системы. А что произойдет, когда этот человек отправится в отпуск или решит уволиться из организации? В подобных ситуациях многие организации могут столкнуться с серьезными проблемами. Независимо от степени избыточности и надежности информационной системы, организация столкнется с большими неприятностями, если никто не знает как она работает, и как следует поступать в аварийных ситуациях. Способность персонала, работающего с системой, подменять друг друга не менее важна чем избыточность аппаратуры. Должна существовать документация всех критически важных процессов в информационной системе, и о том как работает система, должны знать несколько человек. Многие организации пытаясь сэкономить деньги, принебрегают документацией - однако, в большинстве случаев процессы восстановления оказываются более дорогостоящими нежели создание кратких документов. В заключение стоило бы отметить, что документация должна поддерживаться в пригодном для использования состоянии.
- Резервные копии создаются на том же носителе, что и исходные данные.
В течение нескольких последних лет мы сталкивались с еще несколькими тревожными сценариями. Нам приходилось видеть системы резервного копирования, в которых резернвные копии хранились на том же носителе что и исходные данные. Представьте себе ситуацию когда жесткий диск перестает работать. Если при этом все же удастся прочесть резервные копии, вам очень повезет. В большинстве случаев это будет невозможно. Резервные копии и исходные данные должны находиться на разных носителях. В противном случае при попытке восстановления придется столкнуться с проблемами.
- Резервные копии и исходные данные хранятся в одном помещении.
В случае пожара важно, чтобы одна версия данных хранилась в другом помещении. Иначе возможно уничтожение и данных, и резервных копий. В этом случае данные утрачиваются безвозвратно, и их восстановление не представляется возможным.
- Наличие только последней резервной копии.
Существование только последней резервной копии может повлечь за собой проблемы. В большинстве случаев точное время возникновения неполадок неизвестно, поэтому последние резервныекопии так же будут содержать ошибки, в связи с чем восстановление будет затруднено.
### Полезные ссылки: ###
### Мой выбор: ###
FlexBackup
http://flexbackup.sourceforge.net
http://gentoo-wiki.com/HOWTO_Backup - очень толковая дока, что делать и как.
Умеет differential\incrimental\full backups за что и была выбрана.
Синтаксис очень гибкий, маски включений\исключений. Широкий выбор архиваторов.
Тоолза позиционируется как бекап система для одиночных хостов (это мне и нужно.)
Дифференциальные бекапы - такой вид бекапов, когда во все последующие резервные копии бекапятся только изменения, произошедшие с момента создания полной резервной копии.
Таким образом:
#monthly full backup
30 2 1 * * flexbackup -set all -full
#daily differential backups
0 5 2-31/3 * * flexbackup -set all -differential
Раз в месяц создается полный бекап, каждые 3 дня создается дифференциальная копия, относительно полного бекапа.
Чтобы бекапов не накапливалось слишком много, но были как минимум бекапы за текущий и предыдущий месяц:
# Deleting all backups older then 60 days
30 1 1 * * find /mnt/backups/`hostname -s`/flexbackup.0/ -name "*.tar" -a -mtime +60 -delete
Разумеется, что в flexbackup.conf указано сохранять файлы в данную директорию (/mnt/backups/`hostname -s`/flexbackup.0/), а также выставлен тип бекапов "tar"
Все, на отдельном хосте система бекапов настроена.
Далее посредством ssh ключей и rsync делаем синхронизацию директории бекапов удаленного сервера с централизованным сервером хранения бекапов.
Все просто, из стандартных средств, но эффективно ;)
Внимание:
Это все писалось и тестировалось на Linux. На FreeBSD данная система тоже работает, но как минимум в скрипты везде нужно указывать переменные окружения PATH.
RPM для CentOS\Fedora можно скачать по ссылке, либо с моего сайта.
http://rpm.pbone.net/index.php3/stat/4/idpl/5807812/com/flexbackup-1.2.1
rpm -Uvh http://paix.org.ua/tmp/flexbackup-1.2.1-1.el2.re.noarch.rpm
last update: 080709
Home
