Вопрос: Как сделать запланированную резервную копию Linux-сервера


Мне нужно организовать автоматическое резервное копирование баз данных, веб-сайтов, ftp, электронной почты и т. Д. В Ubuntu 9.04, и поскольку я никогда раньше этого не делал, я ищу места для изучения. Что нужно сделать, какое (бесплатное) программное обеспечение, которое я мог бы использовать, советы и рекомендации, лучшие практики и так далее. Если бы вы могли указать мне на соответствующие статьи для новичков, я бы очень признателен


4
2018-01-29 18:33


Источник




Ответы:


Есть много вариантов в зависимости от ваших целей, инфраструктуры и предпочтений в средствах массовой информации.

Сначала вам, вероятно, нужно будет выяснить, как настроить работу cron независимо от того, какое решение вы в конечном итоге собираетесь использовать. Это то, что запускает запланированные задачи на * nix.

Что касается самой резервной копии, я, как правило, rsnapshot поскольку он достаточно прост в настройке и делает то, что мне нужно. Аманда и Бакула - отличные решения, но включают базы данных и другие вещи, которые усложняют резервное копирование и восстановление. Я стараюсь избегать сложных вещей, когда мне нужно что-то надежное, например, в случае резервного копирования. Rsnapshot использует rsync через ssh для передачи данных между системами, чтобы он был безопасным и эффективным. Затем он использует hardlinks, так что у вас есть много моментальных снимков файловой системы, которую вы создаете резервную копию.

Базы данных должны быть обработаны немного специальными b / c, вам нужно либо заблокировать таблицы во время выполнения задания резервного копирования, либо сбрасывать таблицы базы данных в другое место, где вы затем создаете резервную копию, используя любой метод, который вы выберете. Это можно сделать с помощью инструмента, такого как mysqldump, если вы используете MySQL. Этот сброс обычно автоматизируется с использованием задания cron.


5
2018-01-29 19:48



+1: rsnapshot - тоже мой яд. - Javier
Определенно нужно дать rsnapshot еще +1, прежде чем даже прочитать весь пост, о чем я думал. - ScottZ


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

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

Поэтому вопросы, которые вы должны задать себе:

  • цель резервного копирования - «защитить» ваши данные / службы от:

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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


6
2018-01-30 02:52





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

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

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

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


1
2018-01-29 18:41





Кертис Престон написал O'Rэлектронная книга по резервным копиям у него есть Веб-сайт и блог. У него есть некоторые разделы по резервным копиям Linux и инструментам на основе rsync.

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

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

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

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


1
2018-01-29 18:45





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

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

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


1
2018-01-30 15:13





Очень удобно сохранять резервные копии на Amazon S3.

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

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


1
2018-02-07 09:47