Как сделать запланированное резервное копирование сервера Linux

Резервные копии всегда трудно настроить должным образом; особенно потому, что у людей разные потребности, и такие потребности, как правило, представляют собой сочетание резервного копирования "моментальных снимков" данных, архивирования данных, резервного копирования сервера (конфигурации), надежного обслуживания и т. д.).

3dinfluence и davey оба правы: важно попробовать операцию восстановления (как говорит Джоэл), и набор скриптов cron обычно является первым делом; но необходимо выполнить дополнительные действия в зависимости от того, сколько данных вы можете "принять, чтобы потерять", и какой уровень надежности вам нужен.

Итак, вопросы, которые вы должны задать себе:

• Цель резервного копирования - "защитить" ваши данные / сервисы от:

  • аппаратный сбой (локальный), например сбой диска;
  • больший урон, как огонь в здании;
  • ошибка пользователя (случайное удаление) или необходимость восстановления старых данных;
  • выпуски пакетов с ошибками (обычно сложно обновить службы и т. д.).

• допустимое время простоя (и потери данных) в случае разного типа проблемы

  • сбой диска? например. без потерь, без простоев (?)
  • другой аппаратный сбой (МБ, ЦП и т. д.)? один день работы потерян, несколько часов простоя
  • огонь (и вода от пожарного)? одна неделя потеряна, несколько дней простоя
  • землетрясение или затемнение?

В зависимости от ответа на эти вопросы, вы увидите, достаточно ли ежедневных резервных копий или вам нужен сервер с теплым резервированием, находящийся в другом географическом месте.

Я совсем не гуру в этой области, но, возможно, мой пример может дать вам некоторое представление.

Я управляю небольшим (debian) сервером, предоставляю базы данных (postgresql), репозитории subversion, trac-сайты и некоторые другие подобные функции; сервер в основном используется нашей группой по исследованиям и разработкам, поэтому мало людей (~20 клиентов для Subversion) и некоторые инструменты (~50 клиентов для базы данных), но они работают почти 24/24 часа, 7/7 дней (особенно инструменты, которые подпитывают базу данных мерами).

В случае средней проблемы (например, сбоя основного оборудования) допустимо время простоя от 2 до 4 часов (инструменты могут работать локально некоторое время). Так что у меня не было (пока) предупреждающего резервного сервера, а только набор локальных и удаленных резервных копий и дампов.

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

Первая "линия защиты" обеспечивается избыточностью и разбиением диска (что помогает не только в случае сбоя диска, но и для дальнейшего резервного копирования или обновления сервера). Машина оснащена 4 дисками (500 ГБ каждый).

• 2 (мягких) рейдовых массива (тип 1, на 3 диска):
  • маленький, посвященный /boot
  • и большой, используемый lvm (см. ниже)
• 2 группы lvm:
  • сделанный на большом массиве рейдов (+ 1 не рейдовый раздел на 4-м диске)
  • еще один, сделанный только с разделами без рейдов (50 Гб на каждом из первых трех дисков и половина четвертого диска)
• наконец, разделы:
  • / и /var на двух томах lvm от большого рейда; все пользовательские данные хранятся в /var ...
  • не рейдовые расширения первой vgroup зарезервированы для моментальных снимков (lvm)
  • /boot прямо на маленьком массиве raid 1
  • /tmp и специальный /backup на двух lvm (линейные тома) из второй vgroup (без рейда). последний диск используется, распространяется на 3 других зарезервированы для снимков.

Вторая защитная линия - это регулярные резервные копии: они создаются из скриптов cron, которые запускаются, по сути, каждый день (например, hotbackup для svn, сайтов trac, копирование файлов db и т. Д.) Или каждую неделю (дамп базы данных, дамп svn и т. Д.)..) Точные способы выполнения каждой резервной копии зависят от служб; Например, Subversion предоставляет инструменты для (быстрого) горячего резервного копирования (с использованием жестких ссылок и т. д.) и текстового дампа, но для базы данных используется простой rsync, созданный из снимка lvm.

Все эти резервные копии идут в (локальный!) / Резервный раздел (чтобы быть быстрым); этот раздел обычно монтируется только для чтения; два сценария sudoeable используются для повторного связывания его в режиме rw (начало резервного копирования) и обратно в ro (в конце). Семафор, созданный на основе файлов блокировки, используется для одновременного резервного копирования.

Каждый раз, когда / резервная копия переключается на ro (а также каждые 4 часа), запланировано действие по зеркалированию (использование "at" с небольшой задержкой для объединения изменений из третьей строки). Зеркальное отображение выполняется (с использованием rsync) на другом сервере, с которого данные архивируются на лентах (каждый день, с сохранением только один год) и, по сети, на набор удаленных наземных станций.

Чтобы избежать риска потерять весь рабочий день при минимальных затратах на полосу пропускания, также существует третья строка, которая заключается в создании инкрементного резервного копирования - там, где это возможно.

Примеры:

• для подрывной деятельности все ревизии выгружаются в один (сжатый файл) из ловушки post-commit и post-revpropschange (используя svn-backup-dumps)
• для базы данных, используя непрерывное архивирование (& концепция PITR)

Эти приращения сохраняются с использованием той же концепции, что и для ежедневного и еженедельного копирования (сначала в локальный резервный раздел и с небольшой задержкой на втором хосте). Конечно, сценарии ежедневного копирования и еженедельного дампа должны заботиться о чередовании приращений.

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

Наконец, конфигурация самого сервера (для мониторинга работы, если необходимо настроить новый). Поскольку меня не убедило решение для создания призраков (на новой машине будет другое оборудование, конфигурация диска и т. Д.), Я бы настроил отдельный репозиторий Subversion, в который я помещал каждый скрипт или файл конфигурации, которые я редактировал вручную (прямо или косвенно через пользовательский интерфейс). Таким образом, корень файловой системы (/) является рабочей копией. Кроме того, ежедневная задача cron отвечает за сохранение списка установленных пакетов (dpkg), таблиц разделов (fdisk), настроек raid и lvm и так далее.

Кстати, это, безусловно, самое слабое место: конфигурация сервера находится на репозитории Subversion, обслуживаемой "тем же" хостом. В любом случае, при необходимости достаточно легко использовать одну из резервных копий репозитория (быстрое резервное копирование или дамп) с другой машины (даже с Windows).

Кроме того, я также стараюсь добросовестно делать снимки lvm, прежде чем касаться какого-либо скрипта (или обновления пакета) в основной системе. Но время жизни этих снимков lvm должно быть как можно короче из-за большого штрафа, наложенного на другие сервисы.

Ну, я надеюсь, что это может помочь, или, по крайней мере, дает идеи...

Сохранять резервные копии на Amazon S3 очень хорошо.

Для резервного копирования я рекомендую использовать дублирование и сценарий DT-S3-Backup bash.

DT-S3-Backup был разработан для автоматизации и упрощения процесса удаленного резервного копирования с использованием дублирования и Amazon S3. После настройки сценария вы можете легко выполнять резервное копирование, восстановление, проверку и очистку без необходимости запоминать множество различных параметров команд.

Хорошие ответы о политике резервного копирования уже. Я полюбил простой инструмент резервного копирования: Backup Manager.

Диспетчер резервного копирования очень легок (на самом деле только некоторые скрипты) и прост в настройке. Он знает, как создавать резервные копии SVN-репозиториев, баз данных MySQL, и может выполнять определенные команды для резервного копирования других систем, которые нельзя просто скопировать в резервную копию. Он хранит данные резервных копий в стандартных форматах файлов (tar, zip и т. Д.) И может сохранять их во многих различных областях хранения: локальных дисках, FTP-серверах, scp, Amazon S3... возможно, шифруя их с помощью ключа GPG. Еще одним важным моментом является то, что он уже упакован в Debian и Ubuntu.

Безусловно, простой и эффективный способ начать, хотя в конце вы можете захотеть чего-то более продвинутого.

Большинство людей, которых я знаю, используют Bacula для этой цели.

http://www.bacula.org/en/

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

http://www.linux.com/archive/feature/132562

Кертис Престон написал книгу О'Рейли о резервных копиях, которые у него есть на сайте и в блоге. У него есть несколько разделов о резервных копиях Linux и инструментах, основанных на rsync.

Mondo Rescue - это универсальное бесплатное средство резервного копирования и восстановления образов (apt-get install mondo) G4l также является опцией. Эти два хороши для резервного копирования одной коробки.

Аманда является централизованным решением для резервного копирования.

Я бы сказал, что ваши данные важны, для резервного копирования используйте более одного средства, например, rsync для удаленного бокса + cpio для флешки. Все остальное можно восстановить, вы можете переключиться с Ubuntu на Fedora и взять свои данные с собой, это просто займет больше времени, вы никогда не сможете вернуть потерянные данные, поэтому убедитесь, что данные покрыты вдвойне.

Что бы вы ни выбрали. Сделайте несколько восстановлений и почувствуйте себя комфортно. Нет ничего хуже, чем восстанавливать систему посреди ночи, а затем выяснить, каким образом вы ошиблись, а ваши резервные копии были фаршем!