О резервном копировании (с матерком)
Для внутреннего употребления сисадминами и приближенными к ним самостоятельными людьми.
Смысл и принципы
Спаси и сохрани!
Молитва
В условиях поголовной информационной
неграмотности населения из всех действий
для нас главнейшим является резервное копирование.
Люди
С точки зрения сохранности и безопасности информации сотрудники делятся на:
- Пользователей
- Сисадминов
- Самостоятельных людей.
Пользователь неграмотен, капризен и хитрожоп.
Единственный способ сохранить ценную для него информацию - скопировать её туда, откуда он её не достанет без обращения к грамотному, похуистичному и прямолинейному сисадмину.
Сисадмин есть бог, к которому обращается нерадивый пользователь с молитвой о спасении. Пользователя всё равно ждёт АдЪ, но если не сделан бекап, то будет сисадмин ввергнут в тот же АдЪ, что пользователь. И вечно будут просить пользователи его о спасении, а он не сможет их даже послать нахуй.
Начальство есть разновидность пользователей, которых админ не может послать нахуй, и потому АдЪ есть на Земле прямо сейчас.
Самостоятельные люди сохраняют информацию как следует и потому спасают себя сами. По настоящему самостоятельных людей по настоящему мало. Сисадмин их, равно как и они его, со спокойной совестью и совершенно беззлобно шлёт нахуй.
Оборудование
Выходит из строя. Периодически. Резервное копирование должно быть чаще.
- Аппаратные проблемы, ошибки в программах и злые хакеры - тоже пользователи Вашей информации. Только ещё и злонамеренные.
- Именно поэтому резервная копия должна периодически попадать на носитель, не зависимый от основного экземпляра.
- Доступ к резервной копии должен осуществляться способом, принципиально отличным от употребляемого пользователями для доступа к основному экземпляру. Иначе, рано или поздно хитрожопость возьмёт своё, и пользователи (или их злонамеренные версии) доберутся до бекапа сами.
- Требования безопасности и сохранности информации противоречивы, однако это противоречие диалектическое и разрешается грамотным сисадмином.
- Главный элемент безопасности резервной копии - пользователям не должно быть известно, где и как она хранится.
- Организация, не доверяющая своему сисадмину, идёт нахуй.
Помните! Несмотря на все усилия даже правильного сисадмина, работа хотя бы части пользователей всё равно отличается низкой дисциплиной. И потому потери информации по схеме "ой, я не туда мышкой повела" вполне возможны, а троян обладает всеми правами пользователя, на рабочей станции которого он запущен. А сбои памяти на рабочей станции могут приводить к очень интересным искажениям, сразу незаметным.
- Содержимое \\fserver расшарено по сети для специального пользователя (например, backup) с отдельным паролем и правами на чтение всего содержимого \\fserver\all
- На бэкапящей машине запускается сначала скрипт dirlist, формирующий список полных путей, которые надо бекапить в виде отдельных файлов. Этот скрипт полезно иметь отдельным, так как он определяет структуру дальнейшей работы при восстановлении информации - в частности, в большой организации настоятельно рекомендуется разбивка И по крупным подразделениям, и по отдельным пользователям.
- Руками запускается скрипт fullbackup формирующий в каталоге /usr/backup/fserver/текущая_дата-full/ файлы имя_файла_для_каталога.tar.gz c полным содержимым каталогов и файлы скриптов restore.sh, которыми эти каталоги будут восстанавливаться.
- Далее запускается собственно скрипт резервного копирования daybackup, который и кладёт обновления соответствующих каталогов в файлы вида /usr/backup/fserver/текущая_дата/имя_файла_для_каталога.tar.gz и /usr/backup/fserver/текущая_дата/restore.sh
- Также используется файл /usr/backup/fserver/Last для фиксации времени, с которого надо формировать следующий апдейт.
- Следить за достаточностью места на бекапном винте.
- Время от времени создавать копию бекапа на каком-нибудь ещё носителе и откладывать эти копии в сторону.
- Время от времени трясти начальство на винт большего размера для бекапа.
- Вытрясти из пользователя примерную дату (изменения или создания) нужного ему файла, путь к оному или хотя бы - имя файла.
- Пойти в соответствующий дате архив нужного подразделения и вытащить искомое. (Midnight Commander прекрасно для этого подходит).
- При неспособности пользователя вспомнить хотя бы один из трёх параметров (дата, путь, имя) - слать нахуй.
- Создать на новом сервере шару allrestore и разрешить в неё запись пользователю restore с паролем, который прописан в сформированных бекапом скриптах restore.sh.
- Зайти в последний каталог с полным бекапом YYMMDD-full и запустить из него файл restore.sh (из соображений безопасности не имеет установленного права на исполнение!) - он автоматически пройдёт по таким же файлам в более поздних каталогах.
- Восстановить права по вкусу.
man smbclient Известные баги
- Файлы, имеющие дату создания/изменения в будущем, пакуются в каждый из дневных бекапов, пока не наступит эта самая дата. Свойство smbclient в используемом варианте
- Формируются не осмысленные tar файлы с пустыми поддиректориями.
- При копировании с виндового сервера символ № (номер) в именах файлов в ЛУЧШЕМ случае превращается в _ (подчёркивание) при любых мне известных комбинациях настроек кодовых таблиц в smb.conf. :(
Образец скрипта С НЕОБХОДИМЫМИ НАСТРОЙКАМИ как-нибудь выложу. Не немедленно. Сорри. Умный сисадмин по этим рекомендациям, пожалуй, напишет такие скрипты сам. :)
Сергей Яковлев (когда-то для ВНИРО). 22 ноября 2008 года.
Можно использовать этот текст в любых целях, свободно копировать, как с указанием, так и без указания авторства.