Несколько месяцев назад начал заниматься/разбираться в системах резервного копирования. Все полезные доки/ссылки я сохраняю у себя в заметках.
Много чего накопилось, решил поделиться записями, полезными ссылками и личным опытом.
Наиболее респостраненные ошибки при организации резервного копировани баз данных (взято с citrin.ru/backup.html)
— Эти принципы применимы не только к базам данных, но и к резервному копированию в целом.
Отрывок из книги PostgreSQL. Руководство разработчика и администратора. Гешвинде, Шениг В основном при работе с сервером баз данных допускают шесть ошибок:
— Резевные копии вообще отсутствуют.
Не стоит и говорить, что это наверняка приведет к возниконовнию серьезных проблем.
— Резервные копии созднаны, но процесс восстановления никогда не тестировался .
Возможно это одна из наиболее серьезных ошибок, допускаемых при работе с резервными копиями. Администратор создает резервные копии и уверен, что данные защищены от любых неожиданностей. Однако, если неизвестно, как работает восстановление, в аварийных ситуациях можно столкнуться с серьезными проблемами. Если восстановление никогда раньше не проверялось, администратор чувствует себя неуверенно в процессе восстановления, что, в свою очередь, приводит к дополнительным потерям времени и ошибкам. Убедитесь, что вы достаточно хорошо знаете, как восстановливать данные из резервоных копий. Это очень важный аспект, о котором большинство пользователей и администраторов попросту забывает.
— Вы создаете резервные копии, но никто кроме вас о них не знает.
Вообще говоря, машины надежнее людей. Это следует учитывать при разработке систем баз данных и стратегий резервного копирования. Во многих организациях, с которыми нам приходилось иметь дело в течение нескольких последних лет, мы наблюдали весьма опасную тенденцию: человек, который отвечал за резервное копирование или за всю информационную систему, был единственным распологающим всей информацией о состоянии системы. А что произойдет, когда этот человек отправится в отпуск или решит уволиться из организации? В подобных ситуациях многие организации могут столкнуться с серьезными проблемами. Независимо от степени избыточности и надежности информационной системы, организация столкнется с большими неприятностями, если никто не знает как она работает, и как следует поступать в аварийных ситуациях. Способность персонала, работающего с системой, подменять друг друга не менее важна чем избыточность аппаратуры. Должна существовать документация всех критически важных процессов в информационной системе, и о том как работает система, должны знать несколько человек. Многие организации пытаясь сэкономить деньги, принебрегают документацией — однако, в большинстве случаев процессы восстановления оказываются более дорогостоящими нежели создание кратких документов. В заключение стоило бы отметить, что документация должна поддерживаться в пригодном для использования состоянии.
— Резервные копии создаются на том же носителе, что и исходные данные.
В течение нескольких последних лет мы сталкивались с еще несколькими тревожными сценариями. Нам приходилось видеть системы резервного копирования, в которых резернвные копии хранились на том же носителе что и исходные данные. Представьте себе ситуацию когда жесткий диск перестает работать. Если при этом все же удастся прочесть резервные копии, вам очень повезет. В большинстве случаев это будет невозможно. Резервные копии и исходные данные должны находиться на разных носителях. В противном случае при попытке восстановления придется столкнуться с проблемами.
— Резервные копии и исходные данные хранятся в одном помещении.
В случае пожара важно, чтобы одна версия данных хранилась в другом помещении. Иначе возможно уничтожение и данных, и резервных копий. В этом случае данные утрачиваются безвозвратно, и их восстановление не представляется возможным.
— Наличие только последней резервной копии.
Существование только последней резервной копии может повлечь за собой проблемы. В большинстве случаев точное время возникновения неполадок неизвестно, поэтому последние резервныекопии так же будут содержать ошибки, в связи с чем восстановление будет затруднено.
Полезные ссылки:
www.ibm.com/developerworks/ru/library/l-backup/index.html — Автоматизация резервного копирования в Linux
www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/backup-basics.html — Основы технологии резервного копирования
ru.wikipedia.org/wiki/Список_ПО_для_резервного_копирования
en.wikipedia.org/wiki/Rsync
rsync.samba.org/examples.html
www.fredshack.com/docs/rsync.html
everythinglinux.org/rsync
howtoforge.org/rsync_incremental_snapshot_backups
www.mikerubel.org/computers/rsync_snapshots
www.debianhelp.co.uk/backup.htm
www.linux-backup.net
Мой выбор:
FlexBackup
flexbackup.sourceforge.net
gentoo-wiki.com/HOWTO_Backup — очень толковая дока, что делать и как.
Умеет differential\incrimental\full backups за что и была выбрана.
Синтаксис очень гибкий, маски включений\исключений. Широкий выбор архиваторов.
Тоолза позиционируется как бекап система для одиночных хостов (это мне и нужно.)
Дифференциальные бекапы — такой вид бекапов, когда во все последующие резервные копии бекапятся только изменения, произошедшие с момента создания полной резервной копии.
Таким образом:
Раз в месяц создается полный бекап, каждые 3 дня создается дифференциальная копия, относительно полного бекапа.
Чтобы бекапов не накапливалось слишком много, но были как минимум бекапы за текущий и предыдущий месяц:
Разумеется, что в flexbackup.conf указано сохранять файлы в данную директорию (/mnt/backups/`hostname -s`/flexbackup.0/), а также выставлен тип бекапов «tar»
Все, на отдельном хосте система бекапов настроена.
Далее посредством ssh ключей и rsync делаем синхронизацию директории бекапов удаленного сервера с централизованным сервером хранения бекапов.
Все просто, из стандартных средств, но эффективно ;)
Внимание:
Это все писалось и тестировалось на Linux. На FreeBSD данная система тоже работает, но как минимум в скрипты везде нужно указывать переменные окружения PATH.
Много чего накопилось, решил поделиться записями, полезными ссылками и личным опытом.
Наиболее респостраненные ошибки при организации резервного копировани баз данных (взято с citrin.ru/backup.html)
— Эти принципы применимы не только к базам данных, но и к резервному копированию в целом.
Отрывок из книги PostgreSQL. Руководство разработчика и администратора. Гешвинде, Шениг В основном при работе с сервером баз данных допускают шесть ошибок:
— Резевные копии вообще отсутствуют.
Не стоит и говорить, что это наверняка приведет к возниконовнию серьезных проблем.
— Резервные копии созднаны, но процесс восстановления никогда не тестировался .
Возможно это одна из наиболее серьезных ошибок, допускаемых при работе с резервными копиями. Администратор создает резервные копии и уверен, что данные защищены от любых неожиданностей. Однако, если неизвестно, как работает восстановление, в аварийных ситуациях можно столкнуться с серьезными проблемами. Если восстановление никогда раньше не проверялось, администратор чувствует себя неуверенно в процессе восстановления, что, в свою очередь, приводит к дополнительным потерям времени и ошибкам. Убедитесь, что вы достаточно хорошо знаете, как восстановливать данные из резервоных копий. Это очень важный аспект, о котором большинство пользователей и администраторов попросту забывает.
— Вы создаете резервные копии, но никто кроме вас о них не знает.
Вообще говоря, машины надежнее людей. Это следует учитывать при разработке систем баз данных и стратегий резервного копирования. Во многих организациях, с которыми нам приходилось иметь дело в течение нескольких последних лет, мы наблюдали весьма опасную тенденцию: человек, который отвечал за резервное копирование или за всю информационную систему, был единственным распологающим всей информацией о состоянии системы. А что произойдет, когда этот человек отправится в отпуск или решит уволиться из организации? В подобных ситуациях многие организации могут столкнуться с серьезными проблемами. Независимо от степени избыточности и надежности информационной системы, организация столкнется с большими неприятностями, если никто не знает как она работает, и как следует поступать в аварийных ситуациях. Способность персонала, работающего с системой, подменять друг друга не менее важна чем избыточность аппаратуры. Должна существовать документация всех критически важных процессов в информационной системе, и о том как работает система, должны знать несколько человек. Многие организации пытаясь сэкономить деньги, принебрегают документацией — однако, в большинстве случаев процессы восстановления оказываются более дорогостоящими нежели создание кратких документов. В заключение стоило бы отметить, что документация должна поддерживаться в пригодном для использования состоянии.
— Резервные копии создаются на том же носителе, что и исходные данные.
В течение нескольких последних лет мы сталкивались с еще несколькими тревожными сценариями. Нам приходилось видеть системы резервного копирования, в которых резернвные копии хранились на том же носителе что и исходные данные. Представьте себе ситуацию когда жесткий диск перестает работать. Если при этом все же удастся прочесть резервные копии, вам очень повезет. В большинстве случаев это будет невозможно. Резервные копии и исходные данные должны находиться на разных носителях. В противном случае при попытке восстановления придется столкнуться с проблемами.
— Резервные копии и исходные данные хранятся в одном помещении.
В случае пожара важно, чтобы одна версия данных хранилась в другом помещении. Иначе возможно уничтожение и данных, и резервных копий. В этом случае данные утрачиваются безвозвратно, и их восстановление не представляется возможным.
— Наличие только последней резервной копии.
Существование только последней резервной копии может повлечь за собой проблемы. В большинстве случаев точное время возникновения неполадок неизвестно, поэтому последние резервныекопии так же будут содержать ошибки, в связи с чем восстановление будет затруднено.
Полезные ссылки:
www.ibm.com/developerworks/ru/library/l-backup/index.html — Автоматизация резервного копирования в Linux
www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/backup-basics.html — Основы технологии резервного копирования
ru.wikipedia.org/wiki/Список_ПО_для_резервного_копирования
en.wikipedia.org/wiki/Rsync
rsync.samba.org/examples.html
www.fredshack.com/docs/rsync.html
everythinglinux.org/rsync
howtoforge.org/rsync_incremental_snapshot_backups
www.mikerubel.org/computers/rsync_snapshots
www.debianhelp.co.uk/backup.htm
www.linux-backup.net
Мой выбор:
FlexBackup
flexbackup.sourceforge.net
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.
