Правило резервного копирования 3-2-1

От чего защищает каждая цифра

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

Чего правило не покрывает

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

Честный подсчёт копий

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

• Рабочие данные считаются первой копией. Вторая папка на том же диске не является второй копией носителя.
• Зеркало или синхронизация, мгновенно повторяющие удаления, это репликация, а не бэкап: ошибочное удаление или злонамеренное шифрование за секунды попадает на другую сторону.
• «Два типа носителей» означает разные домены отказа: например диск сервера и объектное хранилище или отдельный хост для бэкапов, а не два тома из одного аккаунта провайдера.
• «Вне площадки» лучше понимать как другой провайдер или другой аккаунт, чтобы одна блокировка по оплате или взломанный вход не добрались и до сервера, и до копии.

Если одни учётные данные могут изменить все копии, у вас одна копия с лишними шагами. Поэтому руководство по стратегии бэкапов добавляет копию, которую рабочий сервер удалить не может, а руководство CISA #StopRansomware сочетает офлайн-копии с регулярными проверками. Повторяйте аудит после каждого изменения инфраструктуры.

Проверка цепочки копий в restic и Borg

Снимок в списке не доказывает, что данные внутри можно прочитать. В обоих распространённых инструментах есть проверка, а документация restic объясняет её цену. Обычный restic check проверяет структуру снимков, деревьев и pack-файлов, но не подтверждает, что pack-файлы на диске не изменены. Опция --read-data скачивает и проверяет каждый pack-файл, что основательно, но медленно, а --read-data-subset распределяет эту работу во времени:

restic check
restic check --read-data-subset=1/5
restic restore latest --target /tmp/restore --include /etc/hostname

Если выполнить части с 1/5 по 5/5 за пять отдельных запусков, будет охвачен весь репозиторий. Строка восстановления, в форме из документации по restore, доказывает, что один настоящий файл возвращается. В Borg команда borg check выполняет проверку репозитория и проверку архивов, а --verify-data добавляет полную криптографическую проверку, которая читает, расшифровывает и распаковывает всё и, по словам документации, очень медленна. Не трогайте --repair, пока не сделана копия самого репозитория: документация называет эту функцию потенциально опасной.

Дешёвые проверки запускайте по расписанию, глубокие чередуйте, а о любой ошибке оповещайте, как объясняет руководство по мониторингу.

Связанные термины: Программа-вымогатель (ransomware), Реагирование на инциденты, VPS, RPO и RTO (допустимая потеря данных и время восстановления), Object Lock (неизменяемое хранение объектов).