На VPS у хостера часто крутятся CRM, 1С и файловый архив, а «бэкап» сводится к tar на тот же диск раз в неделю. После сбоя RAID или шифровальщика копий не остаётся. IT предлагает «облако», но кладёт архив в соседний раздел того же сервера. Пока нет схемы 3-2-1 и restore-test, руководитель рискует остаться без восстановления — нужен не рейтинг BaaS, а маршрут: локальный снимок → restic в S3 → проверка восстановления на стенде.
Проблема: Бэкапы «где-то в облаке» без схемы: одна копия на том же сервере, синхронизация вместо версионного архива, ключи S3 в открытом cron, восстановление никто не проверял. После сбоя диска или шифровальщика выясняется, что «облако» — это тот же диск или папка на Яндекс.Диске без шифрования. Непонятно, когда хватит DIY restic, а когда нужен managed Backup Яндекса или enterprise BaaS.
Решение: За 1-2 рабочих дня согласовать с IT схему 3-2-1 (или 3-2-1-1-0), выбрать целевой S3-бакет в российском облаке, настроить restic/rclone или managed-политику, зафиксировать RPO/RTO и провести restore-test до удаления единственной локальной копии.
Коротко от редактора. Три копии на двух носителях, одна — вне площадки (offsite) в S3 РФ. Для Linux на виртуальном сервере с админом на 2-4 ч/мес чаще хватает restic + rclone в Yandex Object Storage, VK Cloud Object Storage или Selectel S3. Для ВМ у того же провайдера без своих скриптов — managed Backup. Без квартального теста восстановления схема на бумаге не работает.
По Wordstat (июнь 2026) запрос «резервное копирование в облако» — 569 показов/мес в России, а «резервное копирование в яндекс облаке» — всего 9. Аудитория ищет общую схему, а не бренд. При этом в рейтинге CNewsMarket BaaS 2026 лидирует K2 (505 баллов) — enterprise-ветка, а не DIY S3 для МСБ. Типичная ошибка: выбрать провайдера по рейтингу, не нарисовав схему копий.
Ниже — маршрут для руководителя: что копировать, куда класть, как сравнить три S3-хранилища и пройти чеклист из 12 пунктов. Создание бакета с нуля — в разделе об облаках; бэкапы managed БД — в материале про облачные базы. Контекст ПДн — в разделе об облаках и безопасности.
Зафиксируйте, что копировать, и задайте RPO/RTO
Начните с перечня систем: файлы CRM, 1С, PostgreSQL, конфиги nginx, ключи (в отдельном защищённом контуре). У каждой системы — владелец данных в бизнесе, не только админ.
RPO (Recovery Point Objective) — сколько данных можно потерять по времени. RTO (Recovery Time Objective) — за сколько часов нужно поднять сервис после сбоя. Для файлового архива МСБ RPO 24 часа часто достаточно; для 1С и CRM согласуйте окно простоя с бизнесом до выбора инструмента.
Простыми словами. RPO — «сколько вчерашней работы сгорит, если сервер упадёт сейчас». RTO — «сколько часов клиенты ждут, пока мы всё поднимем». Без этих двух цифр IT не сможет обосновать ночной бэкап или ежечасный снимок.
- Соберите таблицу: система → объём → критичность → владелец → желаемый RPO/RTO.
- Не копируйте всё подряд: временные каталоги и кэш раздувают счёт в S3.
- Для 1С и PostgreSQL добавьте дампы БД отдельно от файлов (подробнее в гайде по managed БД).
Спроектируйте схему 3-2-1 и защиту от шифровальщика
Правило 3-2-1: три копии данных, на двух разных носителях, одна копия вне основной площадки (offsite). Для 2026 года разумно расширить до 3-2-1-1-0: плюс одна неизменяемая (immutable) копия и ноль непроверенных восстановлений.
На практике схема МСБ выглядит так: локальный снимок или NAS → ночной restic в S3 другого провайдера → (опционально) immutable-копия через S3 Vault у Selectel. Синхронизация папки в облако без версий — не бэкап: шифровальщик или ошибка админа сотрут и «облачную» копию.
Простыми словами. Три копии — как три ключи от склада в разных сейфах. Два носителя — диск на сервере и облачный бакет, а не два раздела на одном диске. Offsite — бакет у другого провайдера или в другом дата-центре, чтобы пожар на одной площадке не уничтожил всё сразу.
Сравните три S3-хранилища в России как цель для бэкапа
S3 — не бренд, а протокол доступа к объектному хранилищу (как HTTP для сайтов). Инструменты restic и rclone работают с любым S3-совместимым бакетом. Сравнивайте продукты, а не абстрактное «облако».
| Хранилище (продукт) | Класс для бэкапов | Шифрование | 152-ФЗ и изоляция | Лучше для | Слабее в |
|---|---|---|---|---|---|
| Yandex Object Storage | STANDARD для частых restore; COLD/ICE для архивов (~68 ₽/мес за 100 ГБ в ICE по калькулятору YC) | restic AES-256 на клиенте | 152-ФЗ, данные в РФ | Экосистема YC: ВМ + бакет + managed Backup в одном кабинете | Исходящий трафик сверх 100 ГБ/мес тарифицируется |
| VK Cloud Object Storage | Бэкапы виртуальных серверов, мультимедиа | restic + rclone (есть официальный blog) | Облако 152-ФЗ, линейка ФСТЭК | Связка ВМ VK → S3 VK; посекундная оплата | Меньше отдельных «ледяных» классов в маркетинге vs Yandex/Selectel |
| Selectel S3 | Cold от 1,14 ₽/ГБ·мес; ice от 0,81 ₽ | restic/rclone; S3 Vault (immutable) | 152-ФЗ УЗ-1, ФСТЭК №21, PCI DSS; 3 копии Tier III | Долгие архивы, защита от удаления админом prod | Запросы к cold/ice дороже — не для частых restore |
Endpoint Selectel S3: `s3.storage.selcloud.ru`. Yandex: `storage.yandexcloud.net`. Ключи и endpoint не кладите в git — только у сервисного пользователя с минимальными правами. Пошаговое создание бакета — в разделе об облаках, здесь считаем, что бакет уже есть или его создаст IT по инструкции.
Выберите: DIY restic в S3 или managed-бэкап
| Подход | Когда выбрать | Пример |
|---|---|---|
| DIY restic → S3 | Linux на виртуальном сервере, бюджет МСБ, админ на 2-4 ч/мес | restic + rclone → любой S3 из таблицы выше |
| Снимки ВМ | Быстрый откат диска у того же провайдера | Снимки Compute у Яндекса или VK |
| Managed agent | ВМ у Яндекса без своих скриптов | managed Backup (роль сервисного аккаунта backup.user) |
| Enterprise BaaS | Много ВМ, 1С/SQL, SLA на восстановление | K2 и др. (рейтинг CNews BaaS 2026) — отдельный проект |
restic (~34,7k звёзд на GitHub) делает инкрементальный бэкап с дедупликацией и шифрованием AES-256 по умолчанию. rclone (~58k звёзд) — «транспорт» в 70+ облаков, в том числе S3. Это программы, а не облачные сервисы: ставятся на ваш сервер, лицензия open-source.
Простыми словами. restic — архиватор с шифрованием, который помнит версии файлов. rclone — курьер, который несёт архив в бакет. managed Backup — как «страховка от провайдера»: агент на ВМ, политики в кабинете, но привязка к одной экосистеме.
Настройте резервное копирование: чеклист из 7 шагов
В реальном проекте эти шаги проходит IT; руководитель проверяет, что каждый пункт задокументирован в runbook (план действий при сбое).
- Шаг 1. Инвентаризация: список систем, объёмов, владельцев и критичности (см. раздел выше).
- Шаг 2. RPO/RTO: согласовать с бизнесом цифры для файлов, 1С и БД; зафиксировать в таблице.
- Шаг 3. Схема 3-2-1: локальная копия + offsite S3 + (при риске шифровальщика) immutable-ветка.
- Шаг 4. Выбор S3: сравнить Yandex Object Storage, VK Cloud Object Storage и Selectel по классу хранения, 152-ФЗ и стоимости архива 100 ГБ.
- Шаг 5. Бакет и ключи: сервисный пользователь, минимальные права IAM, endpoint и секреты вне git (см. гайд по S3).
- Шаг 6. restic + rclone на Linux: rclone config для S3, restic init, пароль репозитория в /etc/restic-password с правами 600, отдельно от S3-ключей.
- Шаг 7. Расписание: systemd timer или cron с restic backup и forget —prune; логи в journald; алерт при ошибке cron.
Для Windows или ВМ только у Яндекса без Linux-админа рассмотрите агент managed Backup (quickstart обновлён 19.06.2026). С 01.09.2025 ужесточены требования к раздельному хранению резервных копий — юридический контур согласуйте до первой выгрузки ПДн.
Для IT в тот же день: тестовый `restic backup` вручную → проверка размера бакета → `restic snapshots` → запись пароля и расписания в runbook → мониторинг exit code в cron.
Проведите restore-test до удаления локальной копии
Бэкап без проверенного восстановления — надежда, а не страховка. Раз в квартал (или после крупного изменения инфраструктуры):
- Поднять тестовую ВМ или каталог, не связанный с продом.
- Выполнить `restic restore` выбранного снимка или развернуть тестовую ВМ из managed-снимка.
- Для БД — восстановить дамп на стенде и проверить выборку.
- Засечь время end-to-end и сравнить с RTO.
- Зафиксировать ответственного и дату следующего теста в runbook.
Типичная ошибка: удалить единственную локальную копию сразу после первой успешной выгрузки в S3, не проверив restore. Правило 3-2-1-1-0 заканчивается на «0» — ноль непроверенных восстановлений.
Чеклист из 12 пунктов перед боевым запуском
Отметьте вместе с IT до перевода схемы в прод:
- Три копии на двух носителях, одна offsite в S3 РФ.
- RPO и RTO записаны и согласованы с бизнесом.
- Шифрование restic включено; пароль репозитория не равен паролю S3.
- Ключи S3 не лежат в открытом cron и не в git.
- Retention настроен (forget/prune), старые снимки не копятся бесконечно.
- Класс хранения cold/ice для архивов, standard — только если часто восстанавливаете.
- Restore-test прошёл в согласованное окно; время ≤ RTO.
- Ответственный и дата следующего restore-test в runbook.
- Мониторинг ошибок backup (почта, Telegram, Zabbix).
- ПДн: бакет в РФ, политика по 152-ФЗ; чеклист SaaS — в материале по безопасности облачных сервисов.
- Локальная копия не удалена до успешного теста.
- Квартальное ревью: размер бакета, актуальность списка систем, повтор restore-test.
Результат, который вы получите. Задокументированная схема 3-2-1, рабочий restic-репозиторий или managed-политика с шифрованием и retention, успешный restore-test, предсказуемый бюджет бэкапа и понятный владелец процесса при сбое.
Каталог облачных провайдеров — в разделе облака и сервисы. Паспорта: Яндекс Облако, VK Облако, Selectel. ПДн и 152-ФЗ — в разделе об облаках; чеклист SaaS — в разделе безопасности.
От редактора. Сначала попросите IT нарисовать схему копий на одной странице — если все стрелки ведут на один диск, обсуждать тарифы S3 рано. Параллельно закажите restore-test файла из вчерашнего снимка: 30 минут на стенде снимают месяцы иллюзий «у нас же есть облако».
Частые вопросы
Чем резервное копирование отличается от синхронизации папки в облако?
Синхронизация зеркалирует текущее состояние: удалили или зашифровали файл — в «облаке» то же самое. Версионный бэкап (restic, managed-политика) хранит снимки на дату и позволяет откатиться к вчерашнему дню.
Когда хватит restic, а когда нужен managed Backup?
restic + S3 — для Linux на виртуальном сервере при наличии админа на несколько часов в месяц. managed Backup — когда ВМ уже у провайдера Яндекса и не хотите писать cron; агент и политики в кабинете, роль backup.user у сервисного аккаунта.
Какой S3 выбрать для архива на годы?
Сравните cold/ice классы: Selectel cold от 1,14 ₽/ГБ·мес и S3 Vault для immutable; Yandex ICE ~68 ₽/мес за 100 ГБ по калькулятору. Частые restore держите в standard, архив — в холодном классе.
Как не раздуть счёт за облачный бэкап?
Retention через `restic forget —prune`, холодный класс для старых снимков, исключение мусорных каталогов из backup, контроль исходящего трафика (у Yandex первые 100 ГБ/мес не тарифицируются).
Нужно ли шифровать бэкап, если бакет уже в российском облаке?
Да. restic шифрует на сервере до отправки (AES-256). Это защита от утечки ключей S3 и от чтения бэкапа при компрометации бакета. С 01.09.2025 требования к раздельному хранению копий ужесточены — согласуйте с юристом.
Как бэкапить 1С и PostgreSQL?
Файлы 1С и дампы PostgreSQL — отдельные job в restic или managed-политики. Настройка managed БД и RPO для баз — в гайде по облачным базам.
Как часто делать restore-test?
Минимум раз в квартал и после смены провайдера или схемы. Запишите время восстановления и сравните с RTO; без записи тест не считается выполненным.
Термины
| Термин | Значение |
|---|---|
| 3-2-1 | Три копии данных, на двух типах носителей, одна копия вне основной площадки. |
| RPO / RTO | Допустимая потеря данных по времени / целевое время восстановления сервиса. |
| S3 | Протокол объектного хранилища; бакет — контейнер для файлов-бэкапов. |
| VPS | Виртуальный сервер — арендованная машина у хостера или провайдера. |
| restic / rclone | Open-source: версионный бэкап с шифрованием / транспорт файлов в бакет. |
| Retention | Политика хранения: сколько дневных, недельных и месячных снимков оставлять. |
Информация и ответственность
Материал носит информационный характер и не является юридической или ИТ-консультацией. Тарифы S3 и политики backup меняются — сверяйте актуальные прайсы у провайдеров перед договором.