Лучший VPS для бэкапов в России

MAATRIX

Резервная копия имеет смысл только тогда, когда лежит отдельно от оригинала. Отдельный VPS под бэкапы — это офсайт-копия из правила 3-2-1, которая переживёт и поломку основного сервера, и локальную аварию. Для инфраструктуры внутри страны российская локация даёт быстрое восстановление и соответствие 152-ФЗ. Разберём расчёт диска, выбор инструмента и настройку автоматики.

Зачем отдельный VPS под бэкапы

Главное правило резервного копирования формулируется как 3-2-1: три копии данных, на двух разных носителях, одна из которых вне площадки. Бэкап, лежащий на том же сервере или в той же стойке, что и оригинал, не спасёт при пожаре, краже или отказе всего узла. Отдельный VPS в другом городе или дата-центре закрывает пункт «вне площадки» и делает схему по-настоящему надёжной.

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

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

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

Почему Россия — оптимальная локация

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

Второй аргумент — закон. Бэкапы почти всегда содержат персональные данные пользователей, а 152-ФЗ требует хранить данные россиян на территории РФ. Резервная копия — это тоже хранение, поэтому вывоз бэкапов с персональными данными за рубеж создаёт риски. Российская локация закрывает вопрос напрямую: и оригинал, и копия остаются в правовом поле страны.

Третий момент — отсутствие зависимости от внешних маршрутов и трансграничных задержек. Трафик копирования не выходит за пределы страны, что делает и заливку, и восстановление стабильными и предсказуемыми. Если же основная инфраструктура за рубежом, тогда логичнее площадка ближе к ней — смотрите разборы в США и в Великобритании.

Сколько диска и ресурсов нужно

Бэкап-сервер — это в первую очередь диск. Процессор и память нужны минимальные: задача упирается в объём хранилища и канал для передачи данных.

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

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

Инструменты для бэкапов

Выбор инструмента определяет и удобство, и эффективность хранения. Сравним три проверенных решения.

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

Шифрование, ключи и проверка восстановления

Бэкап часто содержит самое ценное — базы, документы, ключи, поэтому шифруйте копии. Даже при хранении внутри страны шифрование защищает данные при краже носителя или несанкционированном доступе. Инструменты вроде Borg и restic шифруют на стороне источника, и на сервер попадает уже зашифрованный архив, недоступный без ключа.

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

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

Автоматизация и расписание

Бэкапы должны идти сами, без участия человека, иначе про них забудут. Настройте расписание через cron или systemd-таймеры. Минимальный пример инкрементальной копии с Borg:

export BORG_PASSPHRASE='ваш-ключ'
borg create --stats /backup::'{now}' /var/www /etc /home
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /backup

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

Как выбрать конфигурацию и оплатить

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

С оплатой российской локации проблем нет: MAATRIX принимает карты банков РФ, СБП, криптовалюту и токен MAAT, а настроить регулярное копирование можно за вечер. Вы получаете быстрое восстановление продакшна и соответствие 152-ФЗ для копий с персональными данными.

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