Резервная копия — это независимый от рабочей системы дубликат данных, из которого бизнес можно поднять после поломки диска, кражи ноутбука, ошибки сотрудника или шифровальщика. Настройка сводится к 4 решениям: что копировать, куда складывать, с какой частотой и кто отвечает за проверку. Всё остальное — детали конкретных программ.
Копия, которую ни разу не разворачивали, копией не считается. Большинство историй о потерянных базах заканчивается не отсутствием архивов, а тем, что архивы оказались битыми, пустыми или лежали на том же сервере, что и оригинал. Поэтому регулярная проверка восстановления входит в схему на тех же правах, что и само копирование, и занимает в календаре отдельное место.
Что именно копировать и в каком порядке#
Начните со списка систем, где вообще живут данные. У небольшой компании это чаще всего учётная программа, база сайта и его файлы, CRM или таблицы с клиентами, почта, общий диск с договорами и макетами, кассовое ПО. Сколько строк окажется в списке именно у вас, по чужому шаблону не угадать: набор зависит от того, как сложился учёт и какие сервисы подключали по ходу дела. Поэтому список собирают не по памяти, а обходом рабочих мест — что открыто в браузере, что запускается утром, куда сотрудник складывает файл, когда «просто надо быстро отправить». Список составляют один раз и держат под рукой — без него копируется то, о чём вспомнили, а не то, что нужно.
Дальше каждую позицию оцените одним вопросом: сколько дней компания проработает, если эти сведения исчезнут. Учётная база и клиентская — обычно ноль дней, работа встаёт сразу. Архив макетов терпит неделю или две. Порядок настройки выстраивается по такому ответу, а не по простоте задачи.
Отдельно выпишите то, что на данные не похоже, но без него восстановление невозможно: настройки программ, лицензионные ключи, сертификаты, список доступов к хостингу и домену, реквизиты платёжных подключений. Восстановленная база бесполезна, если её нечем и негде запустить. Признак, что список неполный: на вопрос «где лежит вся информация по клиентам» сотрудники называют разные места.
Куда складывать: правило «3-2-1» на практике#
Ориентир, который проще всего запомнить, — правило «3-2-1»: 3 экземпляра данных, на 2 разных типах носителей, и минимум 1 экземпляр вне офиса. Оригинал и копия на соседних дисках одного сервера не защищают ни от пожара, ни от кражи, ни от того, кто зайдёт под правами администратора.
Копия «вне офиса» на практике — облачное хранилище или диск, который увозят из офиса. У облака есть неочевидное требование: учётная запись для копий должна быть отдельной, а не той же, под которой работают сотрудники. Шифровальщик добирается до всего, к чему есть доступ с заражённой рабочей машины, включая подключённые сетевые папки.
Копии, которые делает хостинг или поставщик сервиса, считать своими нельзя: они лежат в той же инфраструктуре, ограничены по глубине и пропадают вместе с аккаунтом при неоплате. Свою выгрузку базы и файлов держат у себя — она же пригодится, если однажды начнётся перенос сайта к другому провайдеру. Хотя бы один экземпляр стоит держать офлайн, на диске, который физически отключён от сети.
Расписание, глубина хранения и автоматизация#
Частота копирования равна объёму работы, который не жалко потерять. Если бухгалтер вносит документы весь день, ночная копия означает потерю целого рабочего дня — значит, нужна ещё и дневная. Если сведения меняются раз в неделю, ежечасное копирование только тратит место в хранилище.
Глубина хранения важнее частоты, и здесь ошибаются чаще всего. Схема, где новая копия перезаписывает вчерашнюю, бесполезна против шифровальщика и тихой порчи файлов: повреждение замечают не сразу. Битый файл или сорвавшаяся выгрузка задевают в первую очередь то, что открывают редко, и всплывает это только тогда, когда до нужного документа наконец доходят руки. Пока проблему не увидели, единственный архив успевает несколько раз перезаписаться поверх исправной версии, и разворачивать становится нечего. Рабочий минимум — 7 ежедневных копий, 4 еженедельных и 6 ежемесячных.
Копирование должно запускаться по расписанию, а не человеком. Любая схема, где сотрудник раз в неделю нажимает кнопку, заканчивается на первом же отпуске. Задача планировщика, скрипт на сервере, встроенная функция программы — подойдёт что угодно, что работает без напоминаний. Отдельно решите вопрос с шифрованием архива и с тем, кто знает пароль: пароль, известный одному человеку, — ещё одна точка отказа.
Как проверять, что копия действительно рабочая#
Проверка — единственный способ узнать, что копии живые. Раз в квартал разверните архив на чистой машине или во временной среде, запустите систему и откройте 3–5 произвольных документов за разные даты. Сверьте суммы и остатки с рабочей базой. Сходится — схема работает.
Заодно засеките время. Восстановление, которое заняло 6 часов, означает 6 часов простоя в реальной аварии, и такую цифру лучше узнать заранее. Тогда же выясняется, чего не хватает: пароля от архива, дистрибутива нужной версии программы, ключа лицензии, инструкции по запуску.
Признаки беды видны и без разворачивания. Размер архива не меняется несколько дней подряд или, наоборот, резко упал. Журнал пишет «успешно», а файл весит килобайты. Последняя копия сделана раньше, чем позавчера. Настройте оповещение не только на ошибку, но и на отсутствие новой копии: молчащая система выглядит как исправная.
Когда настройку делает подрядчик или приходящий администратор, требования к расписанию, глубине и проверке фиксируют письменно — так же, как при обычной постановке задачи разработчику. Устный ответ «бэкапы там настроены» ничего не гарантирует и не поддаётся проверке.
Вывод: минимальная схема на первую неделю#
Соберите список систем и отметьте те, без которых работа встанет в тот же день. Их и настраивайте первыми, остальное добавите позже. Для каждой включите автоматическое копирование по расписанию, положите один экземпляр в облако под отдельной учётной записью, а ещё один — на диск, который отключается от сети.
Задайте глубину хранения: как минимум неделя ежедневных копий и несколько месячных. Назначьте ответственного человека и поставьте в календарь ежеквартальную проверку восстановления. Она занимает полдня, обходится дешевле любой аварии и заодно показывает реальное время подъёма системы.
Отдельно запишите пароли от архивов, доступы к хостингу и порядок действий при сбое: кто кому звонит, что поднимают первым, за какое время. В момент аварии искать эти сведения будет некогда, а решения придётся принимать быстро и без права на вторую попытку.