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 r...@хост backup имя-подсистемы >файл-бэкапа 2>временный-файл-лога По окончании работы команды, если ее код завершения 0, временный файл лога обнуляется (чтобы гарантировать его пустоту), в противном случае в него дописывается сообщение с кодом завершения (чтобы гарантировать его непустоту), и файл переименовывается в имя, положенное флаг-файлу (имя-подсистемы.flag). ** Подробная схема бэкапа Windows-машины Для Windows-машины мы предполагаем, что она не может принять входящего ssh-соединения, зато может инициировать соединение на бэкап-сервер и имеет достаточно места для одного бэкапа любой из своих подсистем. На ней настраивается at-задание, которое для каждой подсистемы по очереди: - делает бэкап локально - обрабатывает его лог так, чтобы он содержал только ошибки (и был пуст если и только если бэкап прошел без ошибок) - выполняет команду plink -batch -ssh -i файл-закрытого-ключа bac...@backup.lan.cryptocom.ru savebackup дата имя-подсистемы имя-файла-бэкапа <файл-бэкапа - в случае ее неудачи гарантирует непустоту лога и пытается выполнить plink -batch -ssh -i файл-закрытого-ключа bac...@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-частей - каждая с соответствующим логом. Затем проверяется наличие бэкапного носителя, и если он на месте, на него пишется то, что получилось в результате (с шифрованием, если мы решим не шифровать сразу). Результат записи проверяется. В любом случае пишется письмо о результате этой попытки. Письма пишутся админам и Игусу. -- Презерватив - это защита от копирования дурака. -- (С)энта -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
