Бэкапы по правилу 3-2-1: свой сервер для бэкапов

Сервер для бэкапов — это отдельная машина, которая не обслуживает сайт и не крутит базу, а только принимает и хранит копии. Ключевое слово — «отдельная». Архив, лежащий на диске того же сервера, где работает проект, исчезнет вместе с этим сервером: при сбое диска, ошибочном удалении каталога или блокировке аккаунта за неоплату. Под такую машину обычно берут недорогой тариф с большим диском — например, из раздела VPS под хранилище, где сейчас восемь провайдеров и цены начинаются от 140 ₽/мес за 100 ГБ.

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

Почему копия на том же сервере бэкапом не считается

Самая распространённая схема у новичка выглядит так: скрипт каждую ночь складывает архив базы и файлов в каталог /backups на том же VPS. Схема спасает ровно от одного сценария — вы сами удалили нужный файл и хотите вернуть вчерашнюю версию. От всех остальных она не спасает никак.

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

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

Правило 3-2-1: три копии, два носителя, одна вне площадки

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

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

Для небольшого проекта правило раскладывается в понятную конструкцию. Первая копия — сами данные на боевом VPS. Вторая — ночной архив на сервере-хранилище в другом дата-центре того же провайдера. Третья — недельный архив в объектном хранилище или на домашнем NAS. Такая схема обходится в 200–500 ₽/мес и закрывает 95 % реальных аварий.

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

Что именно копировать: файлы, база, конфиги и письма

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

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

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

Что копировать не нужно: кэш, временные файлы, каталоги с зависимостями и логи старше месяца. На типовом проекте это 30–60 % объёма, и вычистить их из архива — самый дешёвый способ сократить счёт за диск.

Полная, инкрементальная и дифференциальная копия: чем они отличаются

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

Полная копия забирает все данные целиком каждый раз. Восстановление простое: берёте один архив нужной даты и разворачиваете. Расплата — объём: тридцать ежедневных полных копий проекта на 20 ГБ займут 600 ГБ.

Инкрементальная копия сохраняет только то, что изменилось со времени предыдущего запуска — любого, полного или инкрементального. Экономия огромная: суточный прирост типового сайта составляет 100–500 МБ вместо 20 ГБ. Но для восстановления нужна вся цепочка: полная копия плюс каждый инкремент по порядку. Повреждён один элемент в середине — дальше цепочка не разворачивается.

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

Объёмы рассчитаны для суточного прироста 400 МБ и приведены ориентировочно: реальные цифры зависят от того, насколько активно меняются файлы.

Рабочая связка для малого проекта — полная копия по воскресеньям и инкременты в остальные дни. Если хранить четыре недельных набора, выйдет 90–130 ГБ на диске и восстановление максимум из семи файлов.

Снапшот виртуальной машины не заменяет резервную копию

Панель управления почти любого провайдера предлагает кнопку «Создать снапшот». Снапшот — моментальный слепок состояния виртуальной машины: диск, память, настройки. Делается он за 10–60 секунд, поэтому его удобно снимать перед обновлением системы.

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

Порядок такой: снапшот — инструмент отката в рамках одной рискованной операции, бэкап на отдельный сервер спасает данные, когда самой виртуальной машины больше нет.

Где хранить резервные копии: четыре площадки и их цена

Вариантов размещения второй и третьей копии четыре, и выбирают между ними по объёму данных и по требуемой скорости доступа.

Первый — отдельный VPS с большим диском. Полный контроль, предсказуемая цена за месяц и привычные инструменты: SFTP для передачи файлов по защищённому каналу и rsync — программа, которая копирует только изменившиеся куски файлов. Второй — объектное хранилище с тарификацией за фактически занятый гигабайт: удобно, когда объём скачет, механику мы разбирали в гайде про S3-хранилище. Третий — домашний NAS или внешний диск: разово дорого, ежемесячно бесплатно, но требует дисциплины. Четвёртый — встроенные бэкапы провайдера, которые закрывают часть задачи, но остаются внутри его инфраструктуры.

Данные проверены 04.09.2026.

Для хранилища процессор и память почти не важны: одного ядра и 1 ГБ оперативной памяти хватает на приём копий с трёх-четырёх боевых серверов. Смотреть надо на цену гигабайта — тариф со 100 ГБ SSD за 140 ₽/мес даёт 1,4 ₽ за гигабайт в месяц, и это хороший ориентир.

Если данных много и скорость доступа некритична, есть смысл посмотреть тарифы на медленных дисках — VPS с HDD обычно дают в три-пять раз больше места за те же деньги. Архив, который трогают раз в неделю, разницы между HDD и SSD не почувствует.

Сколько диска нужно на самом деле: расчёт на примере

Считать объём на глаз — верный способ упереться в заполненный диск через два месяца. Формула: размер полной копии умножаем на число хранимых полных копий, прибавляем суточный прирост за весь срок хранения инкрементов и добавляем 25 % запаса.

Возьмём интернет-магазин: база 3 ГБ, файлы и картинки 15 ГБ, почта 6 ГБ. Полная копия в сжатом виде — около 18 ГБ. Держим четыре недельных полных копии, это 72 ГБ. Суточный прирост 400 МБ, инкременты за 28 дней дают ещё 11 ГБ. Итого 83 ГБ плюс запас 25 % — округляем до 105 ГБ.

Закономерность видна сразу: хранилище выходит объёмнее самого проекта в 2–7 раз, чаще всего — втрое-впятеро. Планируя бюджет, закладывайте не «диск как у боевого сервера», а как минимум втрое больше.

Как поднять сервер для бэкапов за семь шагов

Настройка занимает около часа и не требует ничего, кроме доступа по SSH — защищённого подключения к серверу через командную строку. Ниже — последовательность, которая работает на Ubuntu 24.04 и Debian 12; подробный разбор самих скриптов есть в отдельном гайде про настройку бэкапов VPS.

1. Закажите тариф с диском минимум в три раза больше объёма данных и разверните на нём чистую Ubuntu 24.04. Процессор и память берите стартовые — 1 ядро и 1 ГБ RAM.
2. Создайте на хранилище отдельного пользователя backup без прав администратора и запретите вход по паролю, оставив только ключи. Порт SSH смените со стандартного 22 на любой в диапазоне 20 000–60 000.
3. Сгенерируйте на боевом сервере SSH-ключ командой ssh-keygen -t ed25519 и положите публичную часть на хранилище. Пароль на ключ не ставьте, иначе ночная задача остановится и будет ждать ввода.
4. Установите на боевом сервере инструмент копирования: rsync для файлов и mysqldump или pg_dump для базы. Дамп базы делайте до архивации файлов, а не после.
5. Напишите скрипт, который снимает дамп, упаковывает каталоги в архив и отправляет результат на хранилище командой rsync -az. Флаг -z сжимает данные в канале и экономит трафик на 40–70 %.
6. Поставьте задачу в планировщик cron на ночное время — например, на 03:20, когда нагрузка минимальна. Полную копию запускайте по воскресеньям, инкременты в остальные дни.
7. Добавьте ротацию: скрипт, который удаляет наборы старше 30 дней, и уведомление на почту об успешном или неуспешном завершении. Без ротации диск заполнится, и копирование молча прекратится.

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

Проверка восстановлением: RPO, RTO и учебная тревога

Непроверенная копия — это надежда, а не бэкап. Типичные открытия в день аварии: архив создавался пустым из-за опечатки в пути, дамп базы обрывался по таймауту, ротация удаляла свежие наборы вместо старых.

Два показателя помогают договориться с собой о требованиях. RPO — сколько данных вы готовы потерять, измеряется во времени: при ночном копировании RPO равен 24 часам, то есть заказы за день аварии придётся восстанавливать вручную. RTO — сколько времени займёт возврат к работе. Развернуть 100 ГБ на новом сервере по каналу 100 Мбит/с получится минимум за 2,5 часа, и это без учёта настройки.

Учебная тревога проводится раз в квартал и занимает 40–60 минут. Берёте VPS с почасовой оплатой и разворачиваете на нём копию недельной давности. Поднимаете сайт на техническом домене и проверяете: открывается ли главная, на месте ли последние заказы, работает ли админка. Сервер после проверки удаляете — при почасовой оплате это обходится в 5–15 ₽. Записывайте результат: дата, набор, время разворачивания, что пошло не так.

Шифрование и доступы: чтобы копия не превратилась в утечку

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

Минимум состоит из трёх мер. Передача только по шифрованному каналу — SFTP или rsync поверх SSH; обычный FTP отдаёт логин и пароль открытым текстом. Шифрование архивов на стороне источника, чтобы при доступе к диску хранилища файлы остались нечитаемыми. Отдельные ключи для каждого боевого сервера.

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

Частые ошибки при организации хранения копий

Провалы повторяются от проекта к проекту. Перечисленное ниже встречается в переписке с читателями чаще всего.

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

Частые вопросы

Хватит ли встроенных бэкапов провайдера? Как вторая копия — вполне, обычно они стоят 10–30 % цены сервера. Но они хранятся у того же провайдера и пропадают вместе с аккаунтом, поэтому третью копию держите в другом месте.

Сколько дней хранить копии? Практичный минимум — 30 дней: этого хватает, чтобы заметить порчу данных, которую обнаружили не сразу. Для магазинов и учётных систем разумно добавить один месячный набор с хранением 12 месяцев.

Можно ли использовать под хранилище самый дешёвый тариф? Да, если диска достаточно. Хранилищу не нужны быстрые ядра: 1 ядро и 1 ГБ RAM справляются с приёмом копий. Единственный параметр, на котором нельзя экономить, — объём и надёжность дискового массива.

Чем отличается сервер для бэкапов от объектного хранилища? На сервере вы платите фиксированную сумму за выделенный диск и сами управляете файлами, в объектном хранилище — за фактически занятый объём и обращения. При стабильных 100–200 ГБ сервер обычно дешевле.

Нужно ли копировать сайт, если он лежит на обычном хостинге? Нужно, и по той же схеме. Панель хостинга умеет делать архив, но хранит его на том же аккаунте. Скачивайте архив на сторону — на отдельный сервер или домашний диск — минимум раз в неделю.

Как понять, что копия рабочая, не разворачивая её целиком? Автоматически проверьте три вещи: размер архива отличается от вчерашнего не более чем на 20 %, архив открывается тестовой распаковкой без ошибок, дамп базы заканчивается строкой завершения. Это отсекает 80 % битых копий.

Где хранить резервные копии, если данных больше 1 ТБ? На таких объёмах выделенный сервер с дисками HDD выгоднее любых поштучных тарифов, а вторую копию удобно держать на физическом NAS в офисе. Ключевой параметр в этом случае — не цена диска, а скорость канала: восстановление 1 ТБ по 100 Мбит/с занимает около 24 часов.

Итог

Рабочая схема укладывается в три предложения. Держите три копии на двух площадках, одна из которых не принадлежит вашему основному провайдеру. Копируйте базу дампом, файлы — инкрементами, наборы старше 30 дней удаляйте автоматически. Раз в квартал разворачивайте копию на временном сервере.

Бюджет вопроса для типового проекта — от 140 до 350 ₽/мес за отдельную машину с диском 100 ГБ, что заметно дешевле недели простоя. Актуальные тарифы с большими дисками и сравнение по цене гигабайта собраны в разделе VPS под хранилище данных.