Несколько месяцев назад я начал изучать/понимать системы резервного копирования.
Все полезные документы/ссылки сохраняю в заметках.
У меня накопилось много всего, поэтому решил поделиться своими постами, полезными ссылками и личным опытом.
Наиболее распространенные ошибки при организации резервного копирования баз данных (взято из 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
-
Аутсорсинг — Бизнес-Модель Не Для Новичков
19 Oct, 24 -
Geobulb Led — 7,5 Вт = 60 Вт?
19 Oct, 24 -
Рецепты Eclipse Rcp, Часть I
19 Oct, 24