Система резервного копирования

Для внутреннего употребления сисадминами и приближенными к ним самостоятельными людьми.

Смысл и принципы

Спаси и сохрани!

Молитва

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

Люди

1. Пользователей
2. Сисадминов
3. Самостоятельных людей.

Пользователь неграмотен, капризен и хитрожоп.

Единственный способ сохранить ценную для него информацию – скопировать её туда, откуда он её не достанет без обращения к грамотному, похуистичному и прямолинейному сисадмину.

Сисадмин есть бог, к которому обращается нерадивый пользователь с молитвой о спасении. Пользователя всё равно ждёт АдЪ, но если не сделан бекап, то будет сисадмин ввергнут в тот же АдЪ, что пользователь. И вечно будут просить пользователи его о спасении, а он не сможет их даже послать нахуй.

Начальство есть разновидность пользователей, которых админ не может послать нахуй, и потому АдЪ есть на Земле прямо сейчас.

Самостоятельные люди сохраняют информацию как следует и потому спасают себя сами. По настоящему самостоятельных людей по настоящему мало. Сисадмин их, равно как и они его, со спокойной совестью и совершенно беззлобно шлёт нахуй.

Оборудование

Выходит из строя. Периодически. Резервное копирование должно быть чаще.

1. Аппаратные проблемы, ошибки в программах и злые хакеры - тоже пользователи Вашей информации. Только ещё и злонамеренные.
2. Именно поэтому резервная копия должна периодически попадать на носитель, не зависимый от основного экземпляра.
3. Доступ к резервной копии должен осуществляться способом, принципиально отличным от употребляемого пользователями для доступа к основному экземпляру. Иначе, рано или поздно хитрожопость возьмёт своё, и пользователи (или их злонамеренные версии) доберутся до бекапа сами.

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

1. Требования безопасности и сохранности информации противоречивы, однако это противоречие диалектическое и разрешается грамотным сисадмином.
2. Главный элемент безопасности резервной копии – пользователям не должно быть известно, где и как она хранится.
3. Организация, не доверяющая своему сисадмину, идёт нахуй.

Взаимный бекап на основе RSA шифрования и SSH

Как бекапимся

1. Имеем два сервера. Сервер1 и Сервер2. На них лежит контент - Контент1 и Контент2
2. Для шифрования контента созданы пары ключей:
   Шиф1 - хранится у владельца Сервер1 и Шиф1.pub - используется на Сервер1 в скрипте
   Шиф2 - хранится у владельца Сервер2 и Шиф2.pub - используется на Сервер2 в скрипте
3. Для процедуры резервного копирования созданы пользователи: Юзер1@Сервер1 Юзер2@Сервер2
   Им даны права на чтение Контент1 и Контент2 соответственно.
   Им даны права на запись в Сервер1/Каталог1 и Сервер2/Каталог2 соответственно.
   Под ними запускаются скрипты, которые пакуют контент в
    Сервер1/Каталог1/Бэкап1 (шифруя его с помощью Шиф1.pub) и
    Сервер2/Каталог2/Бэкап2 (шифруя его с помощью Шиф2.pub)
4. Также созданы пользователи Юзер2@Сервер1 и Юзер1@Сервер2.
   Эти пользователи имеют ТОЛЬКО право на чтение из Сервер1/Каталог1 и Сервер2/Каталог2 соответственно. Этим пользователям запрещён вход по паролю и разрешён только вход по секретному ключу.
5. На Сервер1 пользователю Юзер1 создана пара ключей, Ключ1 в Сервер1/~Юзер1/.ssh/id_rsa
    и его публичный ключ Ключ1.pub помещён в Сервер2/~Юзер1/.ssh/authorized_keys
   На Сервер2 пользователю Юзер2 создана пара ключей, Ключ2 в Сервер2/~Юзер2/.ssh/id_rsa
    и его публичный ключ Ключ2.pub помещён в Сервер1/~Юзер2/.ssh/authorized_keys
6. В скрипте взамного бекапа, запускаемого пользователем Юзер1 на Сервер1, имеем строку:
    scp Юзер1@Сервер2:/Каталог2/Бэкап2 /Каталог1/Бэкап2
   В скрипте взамного бекапа, запускаемого пользователем Юзер2 на Сервер2, имеем строку:
    scp Юзер2@Сервер1:/Каталог1/Бэкап1 /Каталог2/Бэкап1

Таким образом, если любой ОДИН из двух серверов будет взломан злоумышленником, большего, чем оный злоумышленник получил на одном сервере, он НЕ получит. И, кроме того, не сможет раскрыть содержимого бекапа (другого сервера).

Как восстанавливаемся

Для процедуры восстановления созданы дополнительные пары секретный-публичный ключ:
 секретный Ключ11 у владельца Сервер1 - публичный ключ Ключ11.pub на Сервер2/Юзер1/.ssh/authorized_keys
 секретный Ключ22 у владельца Сервер2 - публичный ключ Ключ22.pub на Сервер1/Юзер2/.ssh/authorized_keys

Таким образом, обладая секретными Ключ11 И Шиф1, владелец Сервер1 в любой момент времени может получить и раскрыть свой бекап с Сервер2, а также получить (но НЕ раскрыть!) чужой бекап с Сервер2.

 Владелец Сервер1 хранит у себя файлы: Шиф1, Ключ11 и Сервер1/Юзер2/.ssh/authorized_keys
 Владелец Сервер2 хранит у себя файлы: Шиф2, Ключ22 и Сервер2/Юзер1/.ssh/authorized_keys

В случае, если Сервер1 взломан или уничтожен, владелец его:

1. создаёт новый сервер, на нём - пользователей Юзер1 и Юзер2 с соотв правами и файл Сервер1/Юзер2/.ssh/authorized_keys
2. кладёт в Сервер1/~Юзер1/.ssh/id_rsa секретный Ключ11 - теперь это новый секретный ключ юзер1
3. Генерит новый секретный Ключ11
4. ssh Юзер1@Сервер2
    стирает из Сервер2/Юзер1/.ssh/authorized_keys строку старого секретного ключа Ключ1
    и добавляет в Сервер2/Юзер1/.ssh/authorized_keys строку нового секретного ключа
5. scp Юзер1@Сервер2/Каталог1/Бэкап1 ...
    Расшифровывает его с помощью Шиф1 и запускает собственно Контент1
6. Сообщает по любым каналам связи владельцу Сервер2 о смене ключей

FAQ

Почему важно сохранять authorized_keys?
 Потому что именно от этого файла зависит успешное копирование файлов бэкапа на ДРУГОЙ сервер.

Почему не следует перегенерерировать сразу обе пары ключей - Ключ1 и Ключ11?
 Потому что в случае неудачной последовательности:

1. сообщение не доходит
2. Сервер2 гибнет ровно после того, как восстановлен Сервер1
3. владелец Сервер2 восстанавливает по той же схеме свой сервер.

Как контролировать работу процедуры копирования нашего бекапа?
 быстро - в собственном auth.log
 медленно и (сравнительно) небезопасно - залогинившись на Сервер2 как Юзер1 с Ключ11.

Файлсервер виндовой сети и его бекап

1. Содержимое \\fserver расшарено по сети Samba для специального пользователя (например, backup) с отдельным паролем и правами на чтение всего содержимого \\fserver\all
2. На бэкапящей машине запускается сначала скрипт dirlist, формирующий список полных путей, которые надо бекапить в виде отдельных файлов. Этот скрипт полезно иметь отдельным, так как он определяет структуру дальнейшей работы при восстановлении информации - в частности, в большой организации настоятельно рекомендуется разбивка по крупным подразделениям.
3. Руками запускается скрипт fullbackup формирующий в каталоге /usr/backup/fserver/текущая_дата-full/ файлы имя_файла_для_каталога.tar.gz c полным содержимым каталогов и файлы скриптов restore.sh, которыми эти каталоги будут восстанавливаться.
4. Далее запускается собственно скрипт резервного копирования daybackup, который и кладёт обновления соответствующих каталогов в файлы вида /usr/backup/fserver/текущая_дата/имя_файла_для_каталога.tar.gz и /usr/backup/fserver/текущая_дата/restore.sh
5. Также используется файл /usr/backup/fserver/Last для фиксации времени, с которого надо формировать следующий апдейт.

Действия сисадмина в штатном режиме

1. Следить за достаточностью места на бекапном винте.
2. Время от времени создавать копию бекапа на каком-нибудь ещё носителе и откладывать эти копии в сторону.
3. Время от времени трясти начальство на винт большего размера для бекапа.

Восстановление просимого пользователями

1. Вытрясти из пользователя примерную дату (изменения или создания) нужного ему файла, путь к оному или хотя бы – имя файла.
2. Пойти в соответствующий дате архив нужного подразделения и вытащить искомое. (Midnight Commander прекрасно для этого подходит).
3. При неспособности пользователя вспомнить хотя бы один из трёх параметров (дата, путь, имя) – слать нахуй.

Восстановление при проблемах с сервером

1. Создать на новом сервере самбовую шару allrestore и разрешить в неё запись пользователю restore с паролем, который прописан в сформированных бекапом скриптах restore.sh.
2. Зайти в последний каталог с полным бекапом YYMMDD-full и запустить из него файл restore.sh (из соображений безопасности не имеет установленного права на исполнение!) - он автоматически пройдёт по таким же файлам в более поздних каталогах.
3. Восстановить права по вкусу.

Какую документацию курить во изменение системы

Известные баги

1. Файлы, имеющие дату создания/изменения в будущем, пакуются в каждый из дневных бекапов, пока не наступит эта самая дата. Свойство smbclient в используемом варианте
2. Формируются не осмысленные tar файлы с пустыми поддиректориями.
3. При копировании с виндового сервера символ № (номер) в именах файлов в ЛУЧШЕМ случае превращается в _ (подчёркивание) при любых мне известных комбинациях настроек кодовых таблиц в smb.conf. :(

Сергей Яковлев для ВНИРО. 22 ноября 2008 года.

Сергей Яковлев для всех. 4 сентября 2011 года.