Резервное копирование

Что входит в услугу

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

Как это работает по сути

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

Откуда пошла культура резервного копирования

Важно различать два разных механизма. Отказоустойчивость дисков описал коллектив Калифорнийского университета в Беркли — Дэвид Паттерсон, Гарт Гибсон и Рэнди Кац — в статье о RAID в июне 1988 года; RAID защищает от поломки диска, но это не резервная копия и от удаления или шифровальщика не спасает. Инструментом собственно копирования на десятилетия стал rsync: Эндрю Триджелл и Пол Маккеррас представили его алгоритм и утилиту 19 июня 1996 года, впервые сделав передачу только изменившихся частей файлов массовой практикой. Саму формулу надёжности — правило 3-2-1 — сформулировал фотограф Питер Крог в книге о цифровом хранении, обобщив опыт защиты незаменимых архивов. Из этих трёх идей — избыточность, инкрементальная передача и разнесённое хранение — и выросла современная культура бэкапов, на которую мы опираемся.

Почему критична точность настройки

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

На каком стеке мы работаем

Основной инструмент — restic: система резервного копирования с инкрементальными снимками, дедупликацией и сквозным шифрованием, которая умеет складывать копии в облачные хранилища по протоколу S3. Для части задач применяем borg — дедуплицирующий архиватор с похожей моделью, а для простой синхронизации файлов используем проверенный временем rsync. Копии выгружаем в объектное хранилище, совместимое с S3 (например, облако с оплатой за объём и без платы за исходящий трафик), с отдельными ключами доступа под задачу. Шифрование настраивается на стороне клиента, поэтому содержимое копий недоступно даже провайдеру хранилища. Стек открытый и переносимый: процедура восстановления не зависит от конкретного вендора и остаётся у вас вместе с ключами.

Когда появились ключевые инструменты

Инструменты резервного копирования складывались не одно десятилетие. Идея дисковой избыточности RAID была изложена в статье Университета Беркли в июне 1988 года. Утилита rsync, надолго ставшая стандартом инкрементальной передачи, вышла 19 июня 1996 года. Современные дедуплицирующие системы моложе: restic, наш основной инструмент, был опубликован автором Александром Нойманном как версия 0.1.0 в 2015 году, а borg отделился от проекта Attic в том же 2015 году. Эти даты показывают, что надёжное шифрованное копирование с дедупликацией — зрелая, но относительно свежая инженерная практика, которую нужно уметь настраивать под конкретную инфраструктуру. Мы работаем на актуальных версиях и знаем ограничения каждого инструмента, а не полагаемся на одну универсальную кнопку.

Почему это можно доверить нам

Суммарный опыт нашей команды в IT превышает 45 лет, и резервное копирование мы ведём на собственной практике: наши боевые данные уходят зашифрованными инкрементальными снимками restic в облачное хранилище, и процедура восстановления у нас отработана. Мы подходим к задаче как инженеры: определяем критичные данные, строим схему 3-2-1, настраиваем шифрование и ретеншн и обязательно прогоняем тестовое восстановление до того, как объявить бэкап рабочим. Ключи шифрования и доступы остаются у вас — мы не держим ваши данные в заложниках у своего аккаунта. Мы честно предупредим, где экономия на копиях создаёт реальный риск, а где избыточность лишняя. В результате вы получаете не строчку «бэкап включён», а проверенную возможность поднять сервис за минуты после сбоя, взлома или ошибки.