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

    Несколько месяцев назад начал заниматься/разбираться в системах резервного копирования. Все полезные доки/ссылки я сохраняю у себя в заметках.
    Много чего накопилось, решил поделиться записями, полезными ссылками и личным опытом.

    Наиболее респостраненные ошибки при организации резервного копировани баз данных (взято с 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.
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 10

      0
      Юзай habracut!!!
        0
        ой-ой-ой, спс) забыл
        0
        Есть 2 типа людей — те, кто не делает бэкапы, и те, кто уже делает :)
        Спасибо за статью, но основные средства уже давно известны…
          0
          Средства известны, но собирал я все это с разных сайтов/форумов, старых статей. Разумеется, что для опытного сисадмина данная статья не будет полезной. А вот для начинающих ребят (или девушек) как раз.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            спасибки, поправил. бессонная ночь дает о себе знать.
              0
              Имхо, система резервного копирования без каталога — это не серьёзно.
              Каталог даёт множество преимуществ, а единственная OpenSource система с каталогом — bacula.
              Хоть и не очень понятная в настройке, зато очень удобная в критические моменты.
                0
                Gentoo WiKi говорит что страничка про HOWTO_Backup удалена.
                  0
                  Удалять файлы find-ом по дате довольно рисковано.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое