Давайте определимся с терминологией. Что такое резервная копия?Логично предположить, что это копия данных, предварительно сохраненная с целью восстановления в случае уничтожения оригинала.

Отсюда вытекает первое требование — изолированность. Не имеет смысла делать копию документов на квартиру и хранить ее там же, где оригинал. Так не имеет смысла делать копию данных и хранить ее на том же диске/в том же сервере, что и оригинал. Логично? Вполне.

Едем дальше. Если мы делаем копию данных, значит, боимся их потерять. Так? Так. Значит, все резервируемые данные для нас ценны. Так? Снова так. Отсюда второе требование — целостность. Не смысла в копировании без проверки целостности — на выходе мы вполне можем получить битые данные или потерять часть безвозвратно. 

Еще один пункт. Представим, что вы удалили файл. Или не файл, а много файлов. Например, случайно сделали «rm -rf ./ test». И ушли спать, со спокойной совестью. А в полночь произошел… бэкап. Но вот незадача — настроен он был так, что создавал полную копию данных без учета версий и изменений. Т.е. удалил удаленный вами файл и на резервном носителе тоже — сделал вещь, обратную своему назначению. Представили? Третье требование — версионированность. Вы должны иметь возможность вернуть предыдущее состояние своих данных, а не только иметь две одинаковые копии.

Ну и хватит, наверное. Статья ориентирована на SOHO-пользователей, а не на энтерпрайз, поэтому требования к безопасности, скорости disaster recovery, ограниченной избыточности и прочему мы рассматривать не будем.

И что в итоге?

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

Ближе к практике.

Не вопрос.

Анализируя существующую или придумывая для себя новую СРК — подумайте, соответствует ли она критериям, изложенным выше?

Пересекаются ли в одном месте основная и резервная копия? Обеспечивается ли при этом изолированность резервной? Существует ли возможность одновременно изменять файлы в основном и резервном хранилище? Существует ли значительная (более значительная, чем атомный взрыв) вероятность того, что оба носителя будут одновременно уничтожены или утеряны? Если ответ на любой из этих вопросов «да» — в системе есть ошибка. К примеру, если вы сделали бэкап файлов с ноутбука на usb flash и убрали ее в сейф — вы молодец. Если вы сделали этот бэкап и положили флешку в сумку к ноутбуку — вы не сделали бэкап.

Обеспечивает ли ваша схема целостность данных? К примеру, если на резервном носителе закончится место и копия не сможет корректно сохраниться — вы об этом узнаете?

Обеспечивает ли она полноту? Если это приложение — сохранены ли настройки, если база данных — схема и т.д.? 

Можно ли из существующей копии получить работающий оригинал? Или чего-то не хватает?

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

Проведите «учения» — представьте, что основной носитель утрачен и попытайтесь восстановиться. Уверен, с первого раза у вас ничего не выйдет, или выяснится, что многое на самом деле не совсем так, как вы представляли ранее.

Ответили? Провели? Все прекрасно? Нет, не совсем. Не забывайте о СРК. Поддерживайте ее в актуальном состоянии. Начали использовать новое ПО? Внесите его каталоги в список на бэкап. Подумайте, как его восстанавливать. Следите за состоянием резервного носителя (если это одиночный диск, флешка или NAS — он совсем не вечный). Думайте о своих данных, кроме вас этого не сделает никто.

Мифы и примеры плохих решений

Почему-то люди любят обманывать себя. Например, многие верят, что RAID заменяет бэкап и гарантирует сохранность данных. Особенно если RAID не простенький — первый, а навороченный, 5ый например.

Но RAID — не бэкап. Из определенных выше критериев в общем случае не выполняются все три — зеркальные диски не изолированы, не контролируются и не версионируются. Падение файловой системы, случайный «rm -rf /» или ошибка при работе с разделами уничтожит данные на обоих дисках и RAID ничем не поможет их сохранить. Больше того, если поврежденную FS на одном диске обычно можно восстановить хотя-бы частично, то распавшийся массив — почти всегда нет.

Распространенная схема «отдельный HDD для бэкапа» тоже нежизнеспособна. Во-первых, резервные данные доступны и уязвимы для злоумышленника, вируса или обычной ошибки на вроде вышеупомянутого «rm -rf /». Во-вторых, есть множество ситуаций, причем весьма вероятных, которые погубят одновременно оба диска. Например бурная и красивая (со спецэффектами) смерть блока питания. Или опрокинутое на компьютер уборщицей ведро воды. Или… много их.

Утилиты вроде dropbox тоже для бэкапа мало годятся — если, конечно, не предусмотрена версионируемость. Случайно испортив данные в основной копии вы потеряете и резервную, едва между ними синхронизируются изменения. Данные будет уже не вернуть. 

Вместо заключения

Берегите свои данные, потратив 15 минут «до» — можно сэкономить 15 часов «после». Не забывайте бородатый анекдот про тех, кто не делает бэкапы и тех, кто их уже делает.

Джерело