О резервном копировании (с матерком)

[qkowlew]

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

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

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

Люди

С точки зрения сохранности и безопасности информации сотрудники делятся на:

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

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

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

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

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

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

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

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

Поэтому восхваляемое многими аппаратное зеркало (RAID1) НЕ является способом резервного копирования информации и не может заменить его. Аппаратное зеркало – средство минимизировать время простоя при процедуре восстановления работоспособности сети и должно рассматриваться только в таком качестве. Все, кто применяют или требуют применять RAID любого уровня в других целях, идут нахуй.

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

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

---

Правильное устройство файлсервера и его бекапа

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

1. Содержимое \\fserver расшарено по сети для специального пользователя (например, 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. Восстановить права по вкусу.

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

man smbclient

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

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

Образец скрипта С НЕОБХОДИМЫМИ НАСТРОЙКАМИ как-нибудь выложу. Не немедленно. Сорри. Умный сисадмин по этим рекомендациям, пожалуй, напишет такие скрипты сам. :)

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

---

Можно использовать этот текст в любых целях, свободно копировать, как с указанием, так и без указания авторства.

Comments

[besm6.livejournal.com]

Злой ты. А как насчет достаточно свежей копии вне офиса, на предмет восстановления после ситуаций типа пожара?

Вполне за.

[qkowlew.livejournal.com]

Я вообще сторонник того, чтобы одна из копий периодически создавалась в другом городе. :)

Re: Вполне за.

[leonid-.livejournal.com]

в ныне не существующей лавке Borland бэкап жил между Прагой, Петербургом и Калифорнией. При этом ленты выжили только в одном месте, в остальных по подобной вышеописанной схеме информация копировалась на внешний ящик с дисками HP MSA 20, а в ящике всегда лежал настроенный запасной RAID-контроллер.

[nasse.livejournal.com]

Имхо, для виндовых файлов ntbackup лучше. Ибо права сохраяет. Но работать с ним несколько геморройно.

Описанный мной вариант весьма секьюрен и надёжен.

[qkowlew.livejournal.com]

1. На сервере не запускается софта, который может получить доступ к содержимому бекапа.

2. На бекапящей машине нет ни службы сервера, ни каких либо ещё сервисов, доступных для атаки со стороны.

3. Бекапящая машина может включаться только на время собственно процедуры бекапа. Например, в виде ноутбука с вайфаем в машине на стоянке рядом со зданием и коннектиться к точке доступа, на которой прописан единственный валидный мак-адрес.

4. Даже успешный сниффинг пароля пользователя, использующегося для бекапа - может, несомненно, привести к критичному нарушению безопасности (злоумышленник получит копию данных), но не может привести к разрушению ни самих данных, ни к уничтожению бекапа, ни к получению злоумышленником старой информации из бекапа, ныне уже удалённой с сервера.

5. Система позволяет компенсировать частично глупость, недисциплинированность и (в редких случаях) злоумышление штатных пользователей сети при минимальном увеличении затрат и БЕЗ осведомления оных пользователей о том, как это работает. Можно и осведомлять, если хочется. :)

[edo-rus.livejournal.com]

и имеет один недостаток: малопригоден для бэкапов более-менее заметных объёмов

[qkowlew.livejournal.com]

"заметные" - это какие?

чуть менее 1 терабайт - это то, что сейчас бекапится таким образом еженощно (дифф) /ежемесячно (full backup) у меня в одной конторе. Затраты времени на работу скрипта - максимум 1 час, fullbackup - около 4 часов. То есть резерв времени на полный бекап 2 теарабайт у меня там есть. :)