Re: Организация централизованной схемы автоматизированного резервного копирования
DamirX -> debian-russian@lists.debian.org @ Thu, 08 Oct 2009 13:39:49 +0400:
>> Если
>> интересно - могу кинуть, в том числе и в рассылку, внутренний документ
>> фирмы "техническая схема бэкапа". В нем ничего секретного нет, только
>> многабукф.
D> Слёзно просим...
Упомянутый здесь Игус - в данной ипостаси начальник IT-отдела
* Техническая схема бэкапа
** Принципиальная схема
Принципиальная схема бэкапа проста. Есть бэкап-сервер. Есть
бэкапимые подсистемы - такие как "репозитории CVS и SVN", "домашние
директории пользователей на cvs" и т.п. Бэкап-сервер знает, на какой
машине расположена какая подсистема, каков формат ее бэкапа (не как
его парсить, а просто каков он) и какую команду надо выдать (если
вообще какую-то команду надо выдать) этой машине, чтобы получить
очередной бэкап подсистемы. Как его получить - знает только сама эта
машина.
"Получить очередной бэкап" означает получить два файла - собственно
бэкап и лог его ошибок, он же флаг-файл. Момент получения
флаг-файла - это момент завершения бэкапа подсистемы, а его непустота
означает, что бэкап завершился с ошибками.
В определенное время (типа 8 утра) бэкап-сервер проверяет состояние
бэкапов и доступность бэкапного носителя. Если часть бэкапов
завершилась с ошибками, об этом пишется письмо. Затем бэкапы
выливаются на бэкапный носитель, и о результате этой операции (в том
числе и об отсутствии бэкапного носителя) пишется отдельное письмо.
Бэкап-сервер, помимо приема сегодняшнего бэкапа, хранит еще и "last
known good" версию каждой подсистемы, и в случае ошибок сохраняет на
бэкапный носитель еще и ее. Таким образом, за пределами офиса всегда
будет по крайней мере один заведомо живой бэкап каждой подсистемы и
один свежий, независимо от его живости.
При выливании на бэкапный носитель бэкапы шифруются. Умельцев
протерять нешифрованный бэкапный носитель хватает и без нас. Да не
уподобимся. Шифрование производится на gpg-ключах нескольких
сотрудников, достаточно ответственных для того, чтобы не продолбать
свои закрытые ключи.
Возможно, имеет смысл шифровать сразу при сохранении на
бэкап-сервере - это и технически удобнее делать, и меньше шансы, что
ответственные сотрудники забудут пароли от своих закрытых ключей.
** Регламент обращения с бэкапными носителями
Общая идея. В любой момент времени по крайней мере один винчестер с
бэкапами находится вне офиса.
Бэкапные носители (винчестеры с USB-интерфейсом) промаркированы
рабочими днями недели. В свой день недели винчестер подсоединяется к
бэкап-серверу, и ночью на него льется бэкап за этот день. В этот же
день "вчерашний" винчестер уносится из офиса, "позавчерашний"
находится вне офиса весь день, "позапозавчерашний", он же
"послезавтрашний" приносится в офис, а "завтрашний" уже лежит в
офисе.
Штатным уносильщиком и приносильщиком объявляется Игус, а винчестеры,
хранящиеся в офисе, живут в админской.
Уходящий вечером админ проверяет за Игусом, что тот выполнил
регламент, и при необходимости довыполняет его - т.е. подсоединяет
сегодняшний винчестер и забирает к себе домой вчерашний.
В случае, если Игус внезапно не появляется в офисе (и тем самым у него
застревают два винчестера - позавчерашний и позапозавчерашний), админы
переходят на трехвинчестерную схему, не сбиваясь с маркировки, пока
возможно (два дня - возможно).
** Подробная схема бэкапа UNIX-машины
Для UNIX-машины мы предполагаем, что она, вообще говоря, не может
установить входящего соединения на бэкап-сервер (это так по крайней
мере для DMZ-машин, и если мы будем бэкапить что-то внешнее, типа mx2,
то для них тем более). Зато она может принять входящее
ssh-соединение.
Она настраивается так, чтобы владелец определенного ключа (ключа
пользователя backup бэкап-сервера) мог залогиниться под рутом и
выполнить одну команду - по конвенции /usr/local/sbin/do-backup. Ну и
прочие защиты - полный набор будет
command="/usr/local/sbin/do-backup",from="backup.lan.cryptocom.ru",no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding
Эта команда получает через переменную SSH_ORIGINAL_COMMAND команду,
переданную с бэкап-сервера - "backup имя-подсистемы", выдает в stdout
собственно бэкап (в норме в формате .tar.gz), а в stderr - лог ошибок,
и завершается с нулевым кодом если и только если бэкап прошел без
ошибок.
Бэкап инициирует кроновское задание на бэкап-сервере, которое по
очереди для всех подсистем запускает команду
ssh root@хост backup имя-подсистемы >файл-бэкапа 2>временный-файл-лога
По окончании работы команды, если ее код завершения 0, временный файл
лога обнуляется (чтобы гарантировать его пустоту), в противном случае
в него дописывается сообщение с кодом завершения (чтобы гарантировать
его непустоту), и файл переименовывается в имя, положенное флаг-файлу
(имя-подсистемы.flag).
** Подробная схема бэкапа Windows-машины
Для Windows-машины мы предполагаем, что она не может принять входящего
ssh-соединения, зато может инициировать соединение на бэкап-сервер и
имеет достаточно места для одного бэкапа любой из своих подсистем.
На ней настраивается at-задание, которое для каждой подсистемы по
очереди:
- делает бэкап локально
- обрабатывает его лог так, чтобы он содержал только ошибки (и был
пуст если и только если бэкап прошел без ошибок)
- выполняет команду
plink -batch -ssh -i файл-закрытого-ключа backup@backup.lan.cryptocom.ru savebackup дата имя-подсистемы имя-файла-бэкапа <файл-бэкапа
- в случае ее неудачи гарантирует непустоту лога и пытается выполнить
plink -batch -ssh -i файл-закрытого-ключа backup@backup.lan.cryptocom.ru savelog дата имя-подсистемы <файл-лога
Здесь дата - это референсная дата (дата, "за которую" бэкап, а не
текущая на момент выполнения plink).
На бэкап-сервере ~backup/.ssh/authorized_keys настраивается так, чтобы
по соответствующему ключу можно было выполнить только команду
/usr/local/sbin/do-savebackup (опять-таки получающую команду через
$SSH_ORIGINAL_COMMAND), которая из переданных параметров формирует имя
файла, льет в него stdin, а в случае savelog по завершении процедуры
переименовывает лог во флаг-файл.
** Подробная схема анализа завершения и сохранения бэкапов
Кроновское задание, запускаемое на бэкап-сервере часов в 8 утра,
проверяет флаг-файлы по списку. Для каждого существующего, но пустого
флаг-файла соответствующий бэкап становится "last-known-good"
состоянием бэкапа подсистемы, с кодированием в его имени даты. Для
всех остальных (равно непустых и не появившихся флаг-файлов)
"last-known-good" состояние линкуется в директорию с новым бэкапом.
По итогам проверки, если есть хотя бы одна ошибка, пишется письмо. В
сабжекте перечисляются подсистемы, бэкап которых не сросся, а тело
формируется из нескольких текстовых MIME-частей - каждая с
соответствующим логом.
Затем проверяется наличие бэкапного носителя, и если он на месте, на
него пишется то, что получилось в результате (с шифрованием, если мы
решим не шифровать сразу). Результат записи проверяется. В любом
случае пишется письмо о результате этой попытки.
Письма пишутся админам и Игусу.
--
Презерватив - это защита от копирования дурака.
-- (С)энта
Reply to: