Пользователь
0,0
рейтинг
10 января 2011 в 13:31

Администрирование → Бэкапы через bacula на Amazon S3

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

Amazon S3 — это файловое хранилище на облаке Amazon, которое стоит весьма недорого и подходит для архивации любых серверов, постоянно подключенных к интернету. Это могут быть и домашние компьютеры, и офисные серверы, и серверы на площадках датацентров.

Итак, приступаем к настройке. В нашем хозяйстве архивируются офисная локальная сеть и небольшой кластер в датацентре.

Director

Bacula устроена таким образом, что центральную роль в ней играет главный сервер — Director. Его функция — хранить информацию обо всей системе архивации, по расписанию стартовать нужные задачи и логгировать результаты их выполнения. На сервер офисной сети устанавливаем пакет bacula-director-mysql (так он называется в Debian).

У bacula отличная документация по конфигурированию. Остановлюсь только на ключевых настройках. В разделе Catalog указывается адрес MySQL-сервера, где будет храниться индекс архива, название базы данных, имя и пароль. В разделе Messages прописываем e-mail администратора, куда будут сваливаться отчёты о результатах выполнения:

mailcommand = "/usr/lib/bacula/bsmtp -h smtp.example.com -f \"\(Bacula\) %r\" -s \"Bacula daemon message\" %r"
mail = sysadmin@example.com = all, !skipped

Storage

Bacula имеет распределённую архитектуру. Серверы, к которым подключены носители информации, на которые будут записываться архивы, называются Storage. Именно серверы Storage будут взаимодействовать с Amazon S3. В нашей системе нам потребовалось два сервера Storage — один установлен в офисе, прямо на сервере с Director (на него будут бэкапиться все данные с офисных компьютеров), другой на одном из серверов в датацентре (туда будут идти данные с других компьютеров в датацентре). Смысл разделения в том, чтобы не гонять платный трафик между датацентром и офисом.

Зарегистрировавшись на Amazon AWS и создав bucket с выбранным вами именем, у вас на руках окажутся следующие реквизиты: bucket name, access_key и secret_key. Следующим шагом мы воспользуемся модулем s3fs для fuse, чтобы смонтировать наш bucket прямо в файловую систему сервера. s3fs не является частью дистрибутива Debian — его надо будет собрать вручную. Свежие версии почему-то сразу не заработали (были какие-то подвисания после удаления файлов, и приходилось перемонтировать файловую систему), а вот версия 1.16 заработала сразу без единой проблемы. Прописываем в загрузку сервера:

s3fs your-bucket-name /mnt/backup -o allow_other,retries=10,connect_timeout=30,readwrite_timeout=30

И создаём файл /etc/passwd-s3fs с паролями S3:

access_key:secret_key

После того, как файловая система смонтирована, мы установим пакет bacula-sd и попросим bacula сохранять архивные файлы в S3. Для этого в файле конфигурации bacula-sd.conf в разделе Storage указываем Name такой, чтобы нам можно было его легко идентифицировать, например Name=companyname-office-sd, Maximum Concurrent Jobs=1, чтобы не было одновременных обращений к разным файлам через S3. В раздел Director прописываем имя нашего сервера Director и какой-нибудь рандомный пароль. В разделе Storage описываем Device — собственно физическое место для хранения архивов:

Device {
    Name=S3-companyname-office
    Media Type=file
    ArchiveDevice=/mnt/backup/office
    Label Media=yes;
    Random Access=yes;
    AutomaticMount=yes;
    RemovableMedia=no;
    AlwaysOpen=no;
}

Теперь на минуту вернёмся к серверу Director и в его конфиге создадим новый раздел Storage:

Storage {
        Name = S3-companyname-office
        Address = storage.server.domain.name
        SDPort = 9103
        Password = "storage-server-password"
        Device = S3-companyname-office
        Media Type = File
        Maximum Concurrent Jobs = 1
}

Password указываем такой же, как в конфиге Storage в разделе Director.

File Daemon

File Daemon — это собственно демон, устанавливаемый на компьютеры, которые нужно бэкапить. На все машины кластера, на офисные компьютеры, где есть ценные данные, устанавливается пакет bacula-fd и настраивается его конфиг bacula-fd.conf. В разделе Director прописываем идентификатор нашего сервера Director и придумываем новый случайный пароль. На этом его настройка заканчивается, а мы снова возвращаемся к серверу Director, чтобы зарегистрировать нового клиента.

В конфиге Director создаём новый раздел:

Client {
        Name = server-name-fd
        Address = this.server.host.name
        FDPort = 9102
        Catalog = MyCatalog
        Password = "file-server-password"
        Maximum Concurrent Jobs = 1
        AutoPrune = yes
        Job Retention = 365 days
}

Password указываем такой же, как в конфиге File Daemon в разделе Director.

Важный параметр — Job Retention. Через это время старые данные будут удаляться из индекса архивов. Чем это время больше, чем дольше не будут перезаписываться ваши старые архивные файлы, и тем больше денег вы будете платить за Amazon S3. Чем меньше, тем дешевле вам обойдутся бэкапы, но и глубина архивации тоже будет меньше. Кроме того, убедитесь, что полное (Full) архивирование у вас происходит чаще, чем Job Retention, иначе у вас будут моменты, когда старые данные уже удалились, а новые ещё не заархивировались.

Освобождение места

Обратите внимание, что физически данные не стираются из архива, даже если ссылки на них удалены из индекса после истечения интервала Retention. Удаление из индекса просто означает, что на место старых файлов могут быть записаны новые. Место при этом на диске не освобождается, и меньше платить вы не будете, даже если очистите весь индекс. Физически файлы можно либо удалить вручную, убедившись, что на них уже не осталось ссылок в индексе, либо установить свежую версию bacula, которая автоматически умеет делать truncate освобождённым томам. На практике это нужно редко, и мы этой возможностью не пользуемся.

Настройка файрволов

Во время работы bacula требует трёх видов TCP-соединений — от Director к Storage на порт 9103, от Director к File Daemon на порт 9102 и от File Daemon к Storage на порт 9103. Во всех этих направлениях файрволы должны быть открыты, а адреса, которые прописаны в параметрах Address на Storage и File Daemon, должны быть доступны в указанных направлениях. В частности, если у вас вдруг Storage окажется внутри локальной сети, то Director и File Daemon'ы, которые будут на него архивироваться, должны быть тоже внутри той же сети. Если вдруг зачем-то потребуется Storage держать внутри сети, то необходимо настроить маршрутизацию таким образом, чтобы соответствующий порт пробрасывался внутрь сети.

Особенности s3fs

При записи в какой-либо файл s3fs считывает целиком предыдущую версию файла на компьютер, в локальной копии происходят все модификации, и после закрытия файла он целиком заливается обратно на S3. Это означает, что даже дозапись нескольких байт в архивный файл размером 500 мегабайт приведёт к передаче гигабайта по сети. Поскольку трафик на Amazon S3 тарифицируется, то про эту особенность s3fs забывать не стоит. Размер файлов стоит делать не очень большим, чтобы скачивания и заливки обратно были небольшими. У нас заведено по 3 пула на каждом Storage-сервере — для Full-бэкапов (Maximum Volume Bytes=500000000, Volume Retention=12 months), для Diff-бэкапов (Maximum Volume Bytes=300000000, Volume Retention=7 months) и для Incremental-бэкапов (Maximum Volume Bytes=100000000, Volume Retention=2 months). Обратите внимание, что в данном примере дифференциальные бэкапы должны делаться не реже, чем раз в 2 месяца (у нас 1 месяц), иначе будут моменты, когда инкрементальные бэкапы уже удалились, а свежего дифференциального ещё нет. Аналогично полные бэкапы должны делаться не реже, чем раз в 7 месяцев (у нас стоит 6).

Кроме того, поскольку нужно место для хранения локальных копий, нужно, чтобы на файловой системе оно было всегда в наличии. Куда складывать локальные копии, указывается в опции use_cache при монтировании s3fs. По умолчанию — это корневая ФС. Чем больше у вас одновременных файлов открыто, тем больше места там потребуется. Поэтому мы ограничиваем и Maximum Concurrent Jobs на одном Storage-сервере (чтобы много файлов открытыми не держалось), и Maximum Volume Bytes. Если место вдруг закончится, s3fs зависнет и будет ждать освобождения места.

Цена вопроса

Цены за хранение варьируются от 0.037$ за гигабайт в месяц (для больших объёмов хранилищ с пониженной надёжностью 99.99%) до 0.14$ за гигабайт в месяц (для небольших объёмов хранилищ со стандартной надёжностью 99.999999999%). Мы выбрали стандартную надёжность и храним около терабайта архивов — это обходится (вместе со стоимостью трафика) примерно в 180$ в месяц.

Безопасность

Здесь приведу небольшой чеклист, касающийся безопасности:
  • закрыть доступ на чтение для всех к конфигам bacula и к файлу /etc/passwd-s3fs, т.к. записанные там пароли разглашать крайне опасно;
  • ограничить доступ к портам 9101, 9102 и 9103, за исключением нужных для работы bacula направлений;
  • настроить bacula для использования TLS при передаче данных по сетям общего пользования;
  • закрыть каталоги с архивами от любопытных глаз;
  • средствами fuse encryption зашифровать данные, которые будут попадать на Amazon S3;
  • на разные Storage-серверы завести разные S3 buckets, чтобы в случае компрометации одного архива, хакер не получил доступа к другим;
  • регулярно проводите тестовые восстановления, чтобы убедиться, что вы не забыли положить в архивы что-нибудь важное.

Ссылки

Александр Лурье @aml
карма
52,5
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (21)

  • +1
    как по мне 180$ в месяц это очень дорого, тоже думаем над бекапами, но при таких ценах проще свой сервер под бекапы выделить…
    • +2
      От объёма зависит. У вас тоже терабайт?
      • –2
        Еще не терабайт, но все равно… На Amazon бекапить вижу смысл если до 50-100$ влажываться, а дальше проще свой сервер, который кстати сможет не только для бекапов пригодиться.
        • 0
          Надёжность? Своих серверов тогда нужно в разных дата центра и сервера получаются очень не слабые.
          • 0
            Разве проблема, два сервера посадить в два ДЦ?
            а по серверу, то для таких целей подойдет и Atom с 2-я hdd в raid1
            • 0
              Это будет дороже или примерно столько же что и у Amazon. Но нужно будет ещё заморачиватсья с взаимным резервированием, заменой вышедших из строя комплектующих и т.п. А так этим всем Amazon занят :) Правда, если сервера ещё какую-то дополнительную работу делают (что не хорошо, ибо это backup), то сервера конечно же выгоднее будут.
  • +2
    Хм. А у нас получается, что терабайт стоит примерно 3600руб. в месяц. И это без необходимости городить специальные протоколы — NFS, ISCSI, SMB, FTP — всё что угодно на вашем собственном сервере.
    • 0
      оффтопик: а вы не думали сделать услугу аналогичную S3? то есть только сторедж?
      • 0
        У нас нет такого разделения. Мы предоставляем вам свободу конструктора, из него уже можно делать всё, что хотите. Собственно, принимающий и простаивающий сервер будет стоить незначительно на фоне стоимости дисков. Разделять «диски отдельно», «сервера отдельно» я не хочу.
    • 0
      А какой у вас фактор репликации? Если данные в единственном экземпляре, то амазон дешевле будет — около 100$ за терабайт.
      • +1
        термин «фактор репликации» мне не известен, избыточность — сетевой миррор двух RAID60 на двух хранилищах, у самого RAID60 избыточность 4:22.
        • 0
          Я избыточность и имел в виду. Прочитал про RAID60 — похоже, именно так и амазон устроен. Они тоже обещают, что данные не потеряются при выходе из строя любых двух дисков. У вас выходит выгоднее.
    • 0
      прошу прощения, у вас — это где?

      в профайле не нашел информации
  • 0
    Спасибо, интересное решение, в избранное.

    Вопрос такой: не сильно ли тормозит fuse?
    • 0
      Что считать сильно? Из датацентра 500-мегабайтные архивы уходят за 3 минуты, процессор при этом загружен меньше 5%.
  • +1
    Классно! Свой сервер тоже через Bacula бекаплю. Мне интересно — на s3 в принципе не поддерживается простое изменение файлов (дописать пару байт) или это проблемы реализации fuse модуля?
    • +1
      Насколько я знаю, это ограничение самого S3.
  • 0
    Почему каждый пост о бэкапах начинается с фразы про два типа людей?
    • +1
      Потому же, почему в каждой второй маршрутке над дверью наклейка «место для удара головой».
  • 0
    В Virtuozzo клнтейнере как правило хер ты подключишь модуль ядра для работы с FUSE
  • 0
    особо хитроумные пользователи AWS используют EC2 для бекапов и используют там rsync, а на s3 держат только снимки состояния EC2

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