Резервное копирование для малого бизнеса: правило 3-2-1 простыми словами

Резервное копирование — это создание копий данных, из которых можно восстановить работу компании, если оригинал потерян, испорчен или зашифрован злоумышленником. Для малого бизнеса резервное копирование данных — не бюрократическая формальность, а способ не потерять компанию из-за одного сбоя диска или одной неосторожной команды. Правило 3-2-1 даёт простой каркас: три копии, два разных носителя, одна копия вне офиса. Эта статья объясняет резервное копирование для малого бизнеса простыми словами, без жаргона и лишней теории, и заканчивается практическим чеклистом, который можно внедрить за неделю.

Потеря данных почти никогда не бывает «частью работы». Бухгалтерия не сможет выставить счета, отдел продаж потеряет историю сделок, производство встанет без чертежей. Восстановление из бэкапа — это единственное, что отделяет неприятный инцидент от остановки бизнеса. При этом многие компании до 50 человек не имеют регулярного резервного копирования, а те, у кого оно есть, часто ни разу не проверяли, что копии действительно восстанавливаются.

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

О чём эта статья

Резервное копирование (backup) — это практика регулярного создания независимых копий информации и проверки того, что из этих копий можно восстановить данные. Бэкап отличается от синхронизации и репликации: репликация дублирует изменения почти мгновенно, поэтому ошибку или вирус она размножит вместе с полезными данными, а бэкап хранит состояние на момент прошлого запуска и позволяет откатиться назад во времени.

Ключевые термины, которые встречаются в статье:

Для кого эта статья: владельцы и руководители малого и среднего бизнеса, офис-менеджеры, бухгалтеры, которые фактически администрируют офисную сеть, наёмные системные администраторы, а также инженеры в компаниях без выделенного DevOps-отдела.

Что вы узнаете:

• какие реальные сценарии потерь случаются чаще всего и как они выглядят на практике;
• что именно копировать: базы данных, файлы, конфигурации, сайты, почту и знания компании;
• как правило 3-2-1 работает простыми словами и зачем нужно расширение 3-2-1-1-0;
• чем отличаются полный, инкрементальный и дифференциальный бэкапы и что выбрать;
• как выбрать частоту копирования по RPO и время восстановления по RTO;
• как собрать схему для МСБ: локально, на внешний диск и в облако, с шифрованием и версионированием;
• как защититься от рансомвара и почему проверка восстановления важнее самого копирования.

Зачем нужны бэкапы: реальные сценарии потерь

Угроза потери данных не абстрактна. В небольшой компании почти каждая из ситуаций ниже рано или поздно случается, и почти каждая приводит к потере от нескольких часов работы до недель простоя.

Отказ диска. Жёсткие диски и SSD выходят из строя постепенно, а иногда мгновенно. Если рабочая база, бухгалтерия и общие документы лежат на одном диске сервера или на одном компьютере, его отказ означает потерю всего сразу. Типичная картина: сервер с базами проработал пять лет, никто не следил за SMART-атрибутами, утром диск не определяется. Без бэкапа остаётся только дорогостоящее восстановление в лаборатории, и оно тоже не гарантирует результат.

Рансомвар. Шифровальщик проникает через письмо, открытый RDP-порт или уязвимость, шифрует доступные ему файлы и сетевые ресурсы, а затем требует выкуп. Особенность в том, что вирус ищет в первую очередь подключённые сетевые диски и облачные папки, синхронизированные с рабочими компьютерами. Именно поэтому копия, доступная по сетевому пути, часто оказывается зашифрованной вместе с оригиналами.

Ошибка сотрудника. Самая частая и самая недооценённая причина. Случайное удаление папки, перезапись версии документа, «почистил лишнее» в базе, ошибочная миграция, запуск скрипта не на том окружении — всё это не лечится антивирусом и не покрывается репликацией. Здесь спасает только копия с историей версий.

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

Случайное удаление и порча данных. Иногда данные не «пропадают», а тихо портятся: рассинхронизация базы, повреждение индекса, некорректный перенос, сбой при обновлении. Проблема обнаруживается через дни или недели, когда испорченная копия уже разошлась по всем синхронизациям. Версионный бэкап позволяет откатиться на состояние до порчи.

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

Во всех этих историях общий знаменатель один: к моменту обнаружения проблемы оригинальных данных уже нет, и единственный выход — восстановление из независимой копии.

Что бэкапить: карта данных компании

Ошибка новичка — копировать «диск целиком» или, наоборот, только один сервер. Для МСБ разумно составить карту данных и пройтись по ней категориями.

Отдельно стоит проговорить базы данных. Копирование файла работающей СУБД часто даёт повреждённый бэкап, потому что часть изменений ещё находится в памяти. Корректный путь — штатный дамп или снимок средствами самой СУБД. В PostgreSQL, например, есть журнал предзаписи WAL: изменения сначала попадают в него и только потом на диск, и именно этот механизм используется как для восстановления после сбоя, так и для репликации. Но реплика — не замена бэкапу: она повторяет и ошибки тоже.

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

Правило 3-2-1 простыми словами

Правило 3-2-1 звучит так:

• 3 копии данных — оригинал и минимум две резервные копии;
• 2 разных носителя — копии хранятся на дисках или в хранилищах разного типа, чтобы одна отказавшая технология не унесла всё;
• 1 копия вне офиса — минимум одна копия физически находится в другом месте.

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

Пример для компании на 20 человек: оригинал — файлы на офисном сервере и базы на нём же; вторая копия — ежедневный бэкап на сетевой диск в другом крыле офиса; третья копия — зашифрованный архив в облачном хранилище, куда данные попадают ночью. Это уже соответствует 3-2-1.

Расширение 3-2-1-1-0

Современная угроза номер один — рансомвар, поэтому правило расширили до 3-2-1-1-0:

• 1 копия offline или immutable — носитель, физически отключённый от сети, или хранилище с режимом неизменяемости, когда файлы нельзя изменить или удалить в течение заданного срока;
• 0 ошибок восстановления — ноль ошибок при проверке: каждая копия должна регулярно проходить тестовое восстановление.

Два дополнительных условия меняют практику. Offline-копия означает, что диск лежит отключённым и подключается только на время копирования, а immutable-хранилище не даёт удалить данные даже администратору с полными правами. Ноль ошибок восстановления — это не пожелание, а измеримый критерий: если восстановление не проверялось, копия считается несуществующей.

Типы резервного копирования: полный, инкрементальный, дифференциальный

Три базовых типа копий различаются тем, сколько данных они копируют и сколько времени занимает восстановление.

На практике используют комбинацию: раз в неделю делают полную копию, ежедневно — дифференциальную или инкрементальную, а долгосрочное хранение строят на недельных полных копиях. Например, схема «полная копия в воскресенье, дифференциальная каждый будний день» даёт восстановление из двух файлов и предсказуемый объём хранилища. Схема с инкрементами экономит место, но требует целостности всей цепочки: потеря одного промежуточного файла делает восстановление невозможным.

У цепочек есть ещё одно свойство: чем длиннее цепочка, тем больше времени занимает восстановление и тем выше шанс ошибки. Для малого бизнеса предпочтительнее более короткие цепочки и более частые полные копии — место в облаке дешевле, чем часы простоя.

RPO и RTO простыми словами

Два показателя определяют, какой именно бэкап вам нужен.

RPO (Recovery Point Objective) — точка восстановления. Отвечает на вопрос: сколько данных мы готовы потерять, если сбой случится прямо сейчас. Если копии делаются раз в сутки, RPO равен примерно одним суткам: всё, что было введено за день, может быть утрачено. Если копирование идёт каждые 15 минут, потери ограничиваются 15 минутами.

RTO (Recovery Time Objective) — время восстановления. Отвечает на вопрос: как быстро мы обязаны вернуться к работе после сбоя. RTO включает не только сам restore, но и время на обнаружение проблемы, на поиск нужной копии, на развёртывание сервера или базы, на проверку работоспособности.

Как выбрать значения на практике:

• для бухгалтерии и финансов типичны жёсткие требования: потеря даже дня может быть критична;
• для переписки и внутренних документов сутки потерь обычно приемлемы;
• для систем, от которых напрямую зависят продажи, RPO измеряется минутами, а RTO — часами;
• чем строже значения, тем дороже решение, поэтому требования стоит устанавливать по категориям данных, а не для всего сразу.

Полезный приём: сначала спросите бизнес, а не технарей, сколько данных допустимо потерять в каждой системе, и уже потом подбирайте частоту копирования. И обязательно фиксируйте ответы письменно — это часть управления рисками компании.

Как реализовать резервное копирование для МСБ

Локально, на внешний диск и в облако

Рабочая схема для компании без большого ИТ-отдела состоит из трёх слоёв.

Первый слой — локальный быстрый бэкап. Копия на отдельный диск или сетевое хранилище внутри офиса. Она нужна для частых будничных восстановлений: восстановить файл, вернуть ошибочно удалённый документ, откатить базу после неудачного обновления. Локальный слой — самый быстрый, но он не защищает от пожара и не защищает от рансомвара, потому что находится в той же сети.

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

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

Шифрование и версионирование

Шифрование обязательно для всего, что покидает офис: внешние диски с бэкапами так же теряются и крадутся, как ноутбуки. Шифруйте архивы и диски, храните ключи отдельно от копий, в менеджере паролей, а не в текстовом файле рядом с архивом.

Версионирование определяет, насколько глубоко можно откатиться. Политика хранения обычно выглядит так: суточные копии за две недели, недельные за три месяца, месячные за год. Версии нужны не только для отката после порчи данных, но и для расследований: понять, кто и когда изменил важный документ.

Защита от рансомвара

Отдельный контур защиты строится из трёх принципов:

• Offline и immutable. Копия либо физически отключена от сети, либо лежит в хранилище с режимом неизменяемости, где удаление невозможно в течение срока хранения.
• Разные учётные записи и права. Аккаунт, под которым работает бэкап, имеет право только записывать новые копии и не имеет права удалять старые. Аккаунт администратора — отдельный.
• Ротация носителей. Несколько дисков вместо одного: даже если один окажется зашифрован, останутся другие.

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

Главное: проверка восстановления

Самая недооценённая часть резервного копирования — это не создание копий, а проверка того, что они восстанавливаются. Копия, которую никто не пробовал развернуть, — это надежда, а не бэкап. Известны случаи, когда компания годами «делала бэкапы», а в момент аварии обнаруживала, что архивы пусты, зашифрованы забытым паролем или содержат повреждённую базу.

Тестовое восстановление (test restore) должно быть регулярным и документированным:

• раз в месяц — восстановить один произвольный файл и один документ;
• раз в квартал — восстановить базу данных на отдельном стенде и проверить, что приложение с ней работает;
• раз в полгода — провести полное учебное восстановление: развернуть систему с нуля из копий и замерить реальное время;
• после каждого изменения схемы — если поменялась структура базы, обновились версии или сменилось хранилище, проверка обязательна.

У проверки должен быть ответственный человек, названный по имени, и запись о результате: дата, что восстанавливали, сколько заняло, что пошло не так. Без имени и записи проверка не существует. Хорошая практика — хранить журнал проверок вместе с документацией по передаче дел, чтобы новый сотрудник мог продолжить работу без пробелов.

Шаблон-чеклист резервного копирования

Ниже — рабочий чеклист. Его можно скопировать в таблицу и заполнить под свою компанию.

Минимальный план для компании из 5–50 человек

Если ресурсов мало, начните с базового набора, который закрывает большинство рисков:

1. Определите две-три самые критичные системы: обычно это учётная база, файловое хранилище с документами и почта.
2. Настройте ежедневный автоматический бэкап этих систем на отдельный сетевой диск в офисе.
3. Купите два внешних диска и настройте ротацию: один подключён на время копирования, второй лежит вне офиса.
4. Подключите облачное хранилище для зашифрованных копий и держите версии по политике хранения: недельные — три месяца, месячные — год.
5. Закройте одну копию от изменений: отключённый диск или хранилище с режимом неизменяемости.
6. Включите уведомления об ошибках копирования и назначьте ответственного по имени.
7. Проводите восстановление по каденции: файл — ежемесячно, база — ежеквартально, полный учебный тест — раз в полгода.

Такой набор стоит недорого, не требует отдельного сервера и уже соответствует правилу 3-2-1 с расширением до 3-2-1-1-0.

Частые ошибки

Ресурсы

• Шпаргалка по Linux-командам — базовые команды для работы с файлами, дисками и архивами.
• Шпаргалка по Docker — пригодится, если сервисы работают в контейнерах и их нужно восстанавливать.
• Принципы DevOps — культура, автоматизация и мониторинг, без которых бэкапы остаются ручной работой.
• Передача дел системного администратора — как оформить ответственных и журналы проверок.
• Управление рисками — как связать RPO и RTO с рисками бизнеса.

Что дальше

• Принципы DevOps — продолжайте с автоматизации и мониторинга процессов.
• Передача дел системного администратора — закрепите ответственных и документацию.
• Управление рисками — переведите требования по RPO и RTO в язык бизнеса.
• Шпаргалка по Linux-командам — отработайте команды восстановления файлов и архивов.
• Шпаргалка по Docker — восстановите контейнерные сервисы из резервных копий.