Будете бета-тестерами, тэксказать...

[Morleys]

Набиваю цикл статей для своего блога. Суть серии описана в названии и представляет из себя 8 советов на конкретную тему, уже лично мной выстраданную и описанную в "легкой непринужденной манере". На ваш суд представляю статью о бэкапах, далее будет о документировании, виртуализации, 1-level поддержке и т.д. и т.п.

Блог пока недоступен для всеобщего порицания, но надо понимать, что тексты не технические, а идеологические и завязаны на мою очаровательную личность. Вобщем как-то так...

8 умных мыслей о бэкапе.

Как известно, сисадмины делятся на тех, кто бэкапы не делает и тех, кто УЖЕ делает. Эта мудрость всенепременно приведет нас к мысли, что
1. Бэкапы - необходимость.
Не знаю как и зачем разжевывать этот пункт, примите его за аксиому - надо, сталобыть надо! Котэ не обманывает по пустякам

2. Бэкапы бывают разные.
По способу снятия копии:
- диск целиком. Физический или логический.
Удобно применять для системных дисков. Размер бэкапа ~ равен суммарному размеру данных на нем.
- частичная копия. Часть данных с раздела.
Данные имеют свойство изменяться не постоянно. Зачем бэкапить то, что уже есть в предыдущих резервных копиях или представляет из себя только архивную ценность.

По методу выбора данных для резервирования:
- полный (full*)  *здесь используется терминология утилиты ntbackup от MS. В иных системах названия могут отличаться, но не логика.
В резервную копию попадают все файлы, указанные для архивации, независимо ни от чего. Все они помечаются, как прошедшие архивацию.
- копирующий (copy)
То же самое, что полный, с одной тонкостью - статус файлов в разрезе прошли/не прошли архивацию никак не меняется. Данный метод применяется для разовых бэкапов, которые никак нет повлияют на общую логику резервного копирования.
- разностный (differential)
В бэкап попадают все файлы, измененные со времени последнего полного бэкапа. Таким образом для восстановления наиболее актуального состояния необходимо восстановить полный бэкап и поверх него последний разностный.
- добавочный (incremental)
Каждая итерация резервной копии включает в себя только файлы измененые со времени последнего инкрементального бэкапа. Для полной актуализации данных необходимо восстановить крайний полный бэкап и последовательно все добавочные резервные копии. 
- ежедневный (daily)
Бэкап данных, измененных за последний день. Ни одного разумного сценария для применения его в продакшене я так и не придумал. Но он, как тот суслик - есть!

По способу хранения:
- локальный (local)
Хранится на том же сервере, СХД или рабочей станции, которую резервирует. Обеспечивает быстрое восстановление данных, но практически бесполезен в случае отказа железа или системы резервного копирования/восстановления. Ни в коем случае не может быть единственной точкой бэкапа.
- удаленный (remote)
Для любых важных данных обязателен! Расположен в точке, доступной по сети. Чем дальше, тем сложнее, длительней и затратней процедура копирования и восстановления. Зато можно добиться аналога следующего типа.
- вынесенный (off-site)
Бэкап, независимый от работоспособности и доступности физического расположения основных данных. Может представлять из себя коллекцию оптических или жестких дисков вынесенных за пределы фирмы или сетевое хранилище (см. выше) и т.п. Отличительным свойством является полная автономность бэкапов и независимость от любых проблем - потоп/пожар/налоговая/идиот в резервируемом офисе.

3. Избыточность по железу - не замена бэкапу

Увы, на вопрос о резервировании данных, очень часто приходится слышать, что да - у меня есть RAID. Жаль, что многие начинающие (да и продолжающие тоже) администраторы не понимают, что RAID - защита только от отказа части дисковой подсистемы. От случайной или умышленной порчи данных, от фатальных сбоев системы или ПО вас спасет только своевременный бэкап.

4. Не путайте бэкап и версионность.

Вообще, версионность - разновидность бэкапа, но обладает в отличии от него дополнительными свойствами. Помимо обоюдных "что" и "когда", каждая версия несет в себе информацию о том "кто" и/или "почему". Ярким примером тому являются CVS/SVN системы разработки ПО. Надо понимать, что система версионности не требуется для всех данных, а бэкап её (системы) самой вцелом - необходим.

5. Проверяйте бэкапы.

Не стоит расслабляться после того, как продумана и реализована оптимальная схема резервирования. Старайтесь регулярно проверять имеющиеся копии с целью убедиться в соответствии их размера и даты создания предполагаемым. В идеале, раз в несколько месяцев проводите боевые учения по восстановлению бэкапа, чтобы в час ХЭ не удивиться тому, что бэкапилось не то, не так и вообще, программа бэкапа или ваша хитроумная скриптовая обвязка умело плодит пустые файлы.

6. Разделяйте систему и данные.

Данный совет вам пригодится не только в призме организации резервного копирования, но и вообще это хорошая, годная мантра. Системный раздел удобно резервировать дисковыми образами, при этом регулярность бэкапа может быть не высокой, а данные требуют совершенно иного подхода. Мешать все в кучу категорически не разумно!

7. Используйте виртуализацию.

Резервирование виртуальных машин целиком - крайне удобный (хотя и не очень выгодный по затратам дискового пространства) метод. В случае внезапного, но масштабного факапа оборудования у вас всегда будет возможность за разумное время восстановить виртуальную машину на другом хосте, даже заметно менее мощном, с целью обеспечить хотя бы доступность и базовую функциональность необходимых сервисов.
Кроме того, технология снапшотов позволяет подстраховаться в момент установки нового функционала, обновления ПО или ОС и т.п. быстро откатив машину в работоспособное состояние в случае проблем.

8. Документируйте резервное копирование.

Даже если сейчас вам кажется, что система бэкапа прозрачна и очевидна, будьте уверены, что через месяц-два-три вы окажетесь перед проблемой, как и откуда восстановить конкретный документ или откатить ОС на конкретную дату до неудачного обновления. Disaster Recovery Plan - нехитрый документ, описывающий что, куда и зачем резервируется, спасёт ваши волосы на заднице.

Любой фидбэк категорически приветствуется!!

[shs]

Как известно, сисадмины делятся на тех, кто бэкапы не делает и тех, кто УЖЕ делает

IMHO, должна звучать так:
Как известно, сисадмины делятся на тех, кто бэкапы не делал, и тех, кто их УЖЕ делает.   

[Retif]

Morleys, я бы изменил стиль на более строгий, без всяких "котэ" и "волос на заднице". Неуместно это там. Можно стиль сделать попроще, но ты перебарщиваешь, по-моему.

[shs]

Morleys, я бы изменил стиль на более строгий, без всяких "котэ" и "волос на заднице". Неуместно это там. Можно стиль сделать попроще, но ты перебарщиваешь, по-моему.

А, по-моему, хорошо.

[Morleys]

Morleys, я бы изменил стиль на более строгий, без всяких "котэ" и "волос на заднице". Неуместно это там. Можно стиль сделать попроще, но ты перебарщиваешь, по-моему.

Неа. В этом кагбэ и соль, что блог авторский. Это не СМИ, не тематический ресурс, тем более не коммерческий ресурс вовсе. Поэтому могу позволить себе писать как мне нравится   Кому форма подачи материала не нравится могут не читать, я разрешаю...

[Neonaft]

Про system state ничего нет. Ай яй яй коте, так люди могут подумать что Акронис во всем лучше бесплатного ntbackup

[Morleys]

Про system state ничего нет. Ай яй яй коте, так люди могут подумать что Акронис во всем лучше бесплатного ntbackup

Так и задумано.  Текст, еще раз обращаю внимание, идеологический, без привязки к конкретной ОС, ПО и прочим частным случаям. Ну нету во freebsd понятия system state, КЛИНУСЬ!!

[Neonaft]

Так и задумано.  Текст, еще раз обращаю внимание, идеологический, без привязки к конкретной ОС, ПО и прочим частным случаям. Ну нету во freebsd понятия system state, КЛИНУСЬ!!

Тогда нужно сделать пометку для виндузятников что ли, коих большинство. А то о system state мало кто из начинающих (для кого и пишется данный текст) задумывается. Они ставят пирацкий Акронис и думают что все будет хорошо. Так что это надо исправлять сразу и в корне

[Neonaft]

Сделать это можно отдельной умной мыслью.
Например
9. Учитывайте особенности используемой вами ОС

[shs]

Тогда нужно сделать пометку

что

Текст идеологический, без привязки к конкретной ОС, ПО и прочим частным случаям.

[Morleys]

- ежедневный (daily)
Бэкап данных, измененных за последний день. Ни одного разумного сценария для применения его в продакшене я так и не придумал. Но он, как тот суслик - есть!

Вот кстати, забыл спросить, кто-нибудь пользует это?!? И если да, то как и зачем?

[shs]

- ежедневный (daily)
Бэкап данных, измененных за последний день. Ни одного разумного сценария для применения его в продакшене я так и не придумал. Но он, как тот суслик - есть!

Вот кстати, забыл спросить, кто-нибудь пользует это?!? И если да, то как и зачем?

Пользую для бэкапа пользовтаельской файловой помойки. Нужен для того, чтобы была возможность восстановить файл на заданную дату. Ваш КО.

Упс. Был невнимателен. Думал, что речь идет об инкрементальном бэкапе.
Upd
Хотя, судя по описанию, то что тут названо daily backup'ом есть частный случай инкрементального: инкрементальный бэкап, с частотою "один раз в день". Зачем его выделять среди прочих вариантов инкрементального бэкапа - не понимаю.

[Opium]

немного офтопика - а на чём бложик написан будет?=)
CMS какая или готовый сервис?

[Morleys]

Зачем его выделять среди прочих вариантов инкрементального бэкапа - не понимаю.

Вот и я теряюсь в догадках. Там в отличии от простого инкремента есть тонкость - в архив попадают только файлы измененнные в день бэкапа. Сделал в 23-00 получил копии всех доков с которыми работали сегодня. Сделал в 01-00 вероятно получил хуй, ибо все спят.
Я поэтому и не могу реального сценария придумать для его использования. При том, что такой тип бэкапа есть не только в ntbackup, но и в некоторых других системах, в том числе коммерческих.

CMS какая или готовый сервис?

WordPress на мастерхосте. Решил так по следующим причинам:
1. WordPress раскрученный и удобный блоговый движок, самый простой из всех, которые я крутил в руках. На мастерхосте устанавливается и работает "из-каропки" - одним кликом в админке площадки. Есть куча готовых плагинов для всех моих хотелок.
2. Хочу именно standalone, ибо впадлу подчиняться и зависеть от хостера как в плане контента, так и в плане фич, свистелок и перделок. Понимаю, что раскрутка в этом случае сложнее и затратней, но пофиг, ибо не стремлюсь к всемирной известности или монетизации ресурса.  Получится - прекрасно, не получится - не очень и хотелось. Пишу ведь по большей части для удовлетворения графоманского зуда  и упорядочивания собственных мыслей.

[shs]

Так что придумать не сложно: не бэкапируй в 1 час ночи, но в 23. Введен, видимо, для того чтобы упростить работу с планированием бэкапа новичками и/или оставлен для совмстимости со старыми версиями.