Мне нужно организовать автоматическое резервное копирование баз данных, веб-сайтов, ftp, электронной почты и т. Д. В Ubuntu 9.04, и, поскольку я никогда этого раньше не делал, я ищу места для обучения. Что нужно сделать, какое (бесплатное) программное обеспечение я мог бы использовать, советы и рекомендации, лучшие практики и так далее. Если бы вы могли указать мне на соответствующие статьи для начинающих, я был бы очень признателен
Резервные копии всегда сложно настроить должным образом; особенно потому, что у людей разные потребности, и такие потребности обычно представляют собой сочетание резервного копирования «моментального снимка» данных, архивирования данных, резервного копирования сервера (конфигурации), надежного обслуживания и т. д.).
3dinfluence и davey правы: важно попробовать операцию восстановления (как Джоэл говорит), а набор скриптов cron - это обычно первое, что нужно сделать; но необходимо выполнить дополнительные действия в зависимости от того, сколько данных вы можете «принять для потери» и какой уровень надежности вам нужен.
Итак, вам нужно задать себе следующие вопросы:
цель резервного копирования - «защитить» ваши данные / услуги от:
приемлемое время простоя (и потери данных) в случае возникновения проблем другого типа
В зависимости от ответа на эти вопросы вы увидите, достаточно ли ежедневных резервных копий или вам нужен сервер горячего резервирования, находящийся в другом географическом месте.
Я вовсе не гуру в этой области, но, возможно, мой пример даст вам некоторое представление.
Я управляю небольшим (debian) сервером, предоставляя базы данных (postgresql), репозитории Subversion, отслеживание сайтов и некоторые другие подобные функции; сервер в основном используется нашей группой исследований и разработок, поэтому мало людей (~ 20 клиентов для подрывной деятельности) и некоторые инструменты (~ 50 клиентов для базы данных), но они работают почти 24 часа в сутки, 7 дней в неделю (особенно инструменты , которые подпитывают базу данных мерами).
В случае средней проблемы (например, сбоя основного оборудования) приемлемо время простоя от 2 до 4 часов (приборы могут некоторое время работать локально). Так что у меня не было (пока) резервного сервера предупреждения, а только набор локальных и удаленных резервных копий и дампов.
Так что требования совсем не радикальные: около сотни гигабайт данных и менее сотни клиентов для обслуживания.
Первой «линией защиты» является резервирование дисков и разбиение на разделы (которые помогают не только в случае сбоев диска, но и для дальнейшего резервного копирования или обновления сервера). Машина оснащена 4 дисками (по 500 ГБ каждый).
Вторая линия защиты - это регулярные резервные копии: они создаются из сценариев cron, по сути запускаются каждый день (например, горячее резервное копирование для svn, сайтов отслеживания, копирование файлов db и т. Д.) Или каждую неделю (дамп базы данных, дамп svn и т. Д.) .) Точные способы выполнения каждой резервной копии зависят от служб; например, Subversion предоставляет инструменты для (быстрого) горячего резервного копирования (с использованием жестких ссылок и т. д.) и текстового дампа, но для базы данных используется простой rsync, созданный из моментального снимка lvm.
Все эти резервные копии хранятся в (локальном!) / Резервном разделе (чтобы быть быстрым); этот раздел обычно монтируется только для чтения; два сценария sudoeable используются для его повторного связывания в режиме rw (начало резервного копирования) и обратно в ro (в конце). Семафор, созданный для файлов блокировки, используется для одновременного резервного копирования.
Каждый раз, когда / backup переключается на ro (а также каждые 4 часа), планируется действие зеркального копирования (с небольшой задержкой для объединения изменений из третьей строки). Зеркальное копирование выполняется (с использованием rsync) на другой сервер, с которого данные архивируются на ленты (каждый день, с сохранением только в один год) и по сети на набор удаленных станций terra.
Чтобы избежать риска потери рабочего дня при минимальных затратах на полосу пропускания, также существует третья линия, которая заключается в выполнении инкрементного резервного копирования - там, где это возможно.
Примеры:
Эти приращения сохраняются с использованием той же концепции, что и для ежедневного и еженедельного копирования (сначала в локальный раздел резервного копирования и с небольшой задержкой на втором хосте). Конечно, сценарии ежедневного копирования и еженедельного дампа должны заботиться о ротации приращений.
Обратите внимание, что эта третья строка действительно близка к резервному серверу с предупреждением (ну, это необходимый шаг к этой концепции).
Наконец, конфиг самого сервера (чтобы минимизировать работу, если нужно настроить новый). Поскольку меня не убедило решение для фантомного хостинга (новая машина будет иметь другое оборудование, конфигурацию диска и т. Д.), Я бы установил выделенный репозиторий Subversion, в который я поместил каждый скрипт или файл конфигурации, которые я редактировал вручную ( прямо или косвенно через пользовательский интерфейс). Итак, корень файловой системы (/) - это рабочая копия. Кроме того, ежедневная задача cron отвечает за сохранение списка установленных пакетов (dpkg), таблиц разделов (fdisk), настройки raid и lvm и так далее.
Кстати, это, безусловно, самое слабое место: конфигурация сервера находится в репозиториях Subversion, обслуживаемых «тем же» хостом. В любом случае, довольно просто использовать одну из резервных копий репозитория (либо быструю резервную копию, либо дамп) с другой машины (даже с Windows), если это необходимо.
Кроме того, я также стараюсь сознательно делать снимки lvm, прежде чем касаться какого-либо сценария (или обновления пакета) в основной системе. Но время жизни этих снимков lvm должно быть как можно короче из-за больших штрафов, внесенных в другие службы.
Что ж, надеюсь, это поможет или, по крайней мере, даст идеи ...
Есть много вариантов в зависимости от ваших целей, инфраструктуры и медиа-предпочтений.
Сначала вам, вероятно, потребуется выяснить, как настраивать задания cron, независимо от того, какое решение вы в конечном итоге выберете. Это то, что запускает запланированные задачи на * nix.
Что касается самой резервной копии, я предпочитаю rsnapshot поскольку он достаточно прост в настройке и делает то, что мне нужно. Amanda и Bacula - отличные решения, но они включают базы данных и другие вещи, которые усложняют резервное копирование и восстановление. Я стараюсь избегать сложных вещей, когда мне нужно что-то надежное, например, в случае резервного копирования. Rsnapshot использует rsync поверх ssh для передачи данных между системами, что обеспечивает безопасность и эффективность. Затем он использует жесткие ссылки, чтобы у вас было много моментальных снимков файловой системы, для которой вы создаете резервную копию.
Базы данных должны обрабатываться немного особым образом, так как вам нужно либо заблокировать таблицы, пока вы выполняете задание резервного копирования, либо выгрузить таблицы базы данных в другое место, где вы затем выполните резервное копирование, используя любой выбранный вами метод. Это можно сделать с помощью такого инструмента, как mysqldump, если вы используете MySQL. Этот дамп обычно автоматизируется с помощью задания cron.
Уже есть хорошие ответы по политикам резервного копирования. Мне очень понравился простой инструмент резервного копирования: Менеджер резервного копирования.
Backup Manager очень легкий (на самом деле всего несколько скриптов) и прост в настройке. Он знает, как создавать резервные копии репозиториев SVN, баз данных MySQL и может запускать определенные команды для резервного копирования других систем, которые вы не можете просто скопировать в резервную копию. Он хранит данные резервных копий в стандартных форматах файлов (tar, zip и т. Д.) И может сохранять их во многих различных областях хранения: локальные диски, FTP-серверы, scp, Amazon S3 ... возможно, шифруя их с помощью ключа GPG в пути. Еще один важный момент - это то, что он уже упакован в Debian и Ubuntu.
Определенно простой и эффективный способ начать, хотя в конце вам может понадобиться что-то более продвинутое.
Кертис Престон написал O'RИлли книга о резервных копиях у него есть интернет сайт и блог. У него есть разделы о резервном копировании Linux и инструментах на основе rsync.
Mondo Rescue это универсальный бесплатный инструмент для резервного копирования / восстановления изображений (apt-get install mondo) G4l тоже вариант. Эти два хороши для резервного копирования одного ящика.
Аманда это централизованное решение для резервного копирования.
Я бы сказал, что ваши данные - это важная вещь, для резервного копирования используйте более одного средства, например rsync к удаленному ящику + cpio к USB-накопителю. Все остальное можно восстановить, вы можете переключиться с ubuntu на Fedora и взять свои данные с собой, это просто требует больше работы, вы никогда не сможете вернуть потерянные данные, поэтому дважды убедитесь, что у вас есть данные.
Что бы вы ни выбрали. Сделайте несколько восстановлений и расслабьтесь. Нет ничего хуже, чем восстанавливать систему посреди ночи, а затем на собственном горьком опыте выяснять, что у вас что-то не так, а ваши резервные копии очень мелкие!
Большинство людей, которых я знаю, используют для этой цели Bacula.
У них довольно приличная документация, но вот статья, которая познакомит вас с некоторыми основами.
На Amazon S3 очень хорошо сохранять резервные копии.
Для резервных копий рекомендую использовать дублирование и DT-S3-Резервное копирование bash скрипт.
DT-S3-Backup был разработан для автоматизации и упрощения процесса удаленного резервного копирования с использованием дублирования и Amazon S3. После настройки сценария вы можете легко создавать резервные копии, восстанавливать, проверять и очищать, не запоминая множество различных параметров команд.