Системы Резервного Копирования

Несколько месяцев назад я начал изучать/понимать системы резервного копирования.

Все полезные документы/ссылки сохраняю в заметках.

У меня накопилось много всего, поэтому решил поделиться своими постами, полезными ссылками и личным опытом.

Наиболее распространенные ошибки при организации резервного копирования баз данных (взято из 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/List_software_for_backup_copying ru.wikipedia.org/wiki/Rsync rsync.samba.org/examples.html www.fredshack.com/docs/rsync.html alllinux.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 — очень умный документ о том, что и как делать.

Он может выполнять дифференциальное\дополнительное\полное резервное копирование, поэтому он и был выбран.

Синтаксис очень гибкий, маски включения/исключения.

Широкий выбор архиваторов.

Toolza позиционируется как система резервного копирования для одиночных хостов (это то, что мне нужно).

Дифференциальное резервное копирование — это тип резервного копирования, при котором во всех последующих резервных копиях копируются только изменения, произошедшие с момента создания полной резервной копии.

Таким образом:

#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 должны быть указаны в скриптах везде.

Теги: #Резервное копирование #unix #linux #Closet

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.