[Главная](https://servhidden.com/ru) /
[Руководства по приватному хостингу](https://servhidden.com/ru/guides) /
Бэкап VPS: шифрование, второй провайдер, проверенное восстановление






Эксплуатация


# Бэкап VPS, который реально восстанавливается



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


[Читать руководство](#guide-body)
[FAQ](#guide-faq)






## На этой странице




- [Руководство](#guide-body)

- [FAQ](#guide-faq)

- [Похожие руководства](#guide-related)

- [Рекомендуемые страницы](#guide-cta)






Без KYC
Только крипто
Без логов
DMCA игнорируется
Полный root
NVMe SSD





18 мин чтения
Обновлено Aug 2026

На этой странице

[01Что на самом деле убивает серверы](#Что-на-самом-деле-убивает-серверы)
[02Снапшот — это не бэкап, и ваш хостер тоже не бэкап](#Снапшот-это-не-бэкап-и-ваш-хостер-тоже-не-бэкап)
[03Правило 3-2-1, переписанное для тех, кто никогда не показывал документы](#Правило-3-2-1-переписанное-для-тех-кто-никогда-не-показывал-)
[04Push, pull и ошибка, из-за которой одна плохая ночь съедает обе копии](#push-pull-и-ошибка-из-за-которой-одна-плохая-ночь-съедает-об)
[05Шифруйте на источнике, а затем решайте, кто держит ключ](#Шифруйте-на-источнике-а-затем-решайте-кто-держит-ключ)
[06Выбор инструмента одной таблицей](#Выбор-инструмента-одной-таблицей)
[07Всё, что запущено, — это не файл](#Всё-что-запущено-это-не-файл)
[08Что бэкапить и что все забывают](#Что-бэкапить-и-что-все-забывают)
[09Непроверенное восстановление — это слух](#Непроверенное-восстановление-это-слух)
[10Автоматизация, чтобы это продолжало происходить](#Автоматизация-чтобы-это-продолжало-происходить)
[11Краткая версия](#Краткая-версия)
[FAQЧастые вопросы](#guide-faq)
[→Рекомендуемые страницы](#guide-cta)







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

Хостинг, который никогда не спрашивал вашу личность, взамен от чего-то отказывается — и здесь честно об этом сказать. Здесь нет менеджера, которому можно позвонить, нет тикета, который воскресит стёртый том, и [наша собственная политика хранения](https://servhidden.com/ru/privacy) прямо называет причину: данные сервера уничтожаются в течение 24 часов после его удаления, диски криптографически стираются, а не форматируются, и **никакие бэкапы не хранятся**. Это то же самое свойство, за которое платформу и выбирают — просто с другой стороны. Всё, что вы захотите вернуть после плохой ночи, должно уже лежать где-то ещё, и положить его туда — ваша задача.

## Что на самом деле убивает серверы

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

| Что идёт не так | Как это обычно происходит | Что вас спасёт |
| --- | --- | --- |
| **Собственная рука** | rm -rf с пустой переменной окружения, миграция, указавшая на продакшен, деплой, уронивший не ту таблицу | Любая копия вне сервера, снятая *до* ошибки — а значит, глубина хранения должна перекрывать время, за которое вы это заметите |
| **Тихая порча данных** | Умирающий NVMe, оборванная запись при перезагрузке, база, неделю писавшая повреждённые строки | Версионные копии, уходящие достаточно глубоко, чтобы найти заведомо рабочую точку. Единственная зеркальная копия добросовестно отражает и повреждение |
| **Компрометация** | Украденный ключ, непропатченное приложение, отравленная зависимость — а затем, уже осознанно, ваши бэкапы | Копия, которую скомпрометированная машина не могла удалить. Здесь считается только это |
| **Инцидент у провайдера или в стране** | Потеря оборудования, судебное действие в дата-центре, аккаунт или токен, к которому вы больше не можете достучаться | Копия, которая не у этого провайдера и не под этой юрисдикцией |
| **Потеря ключа** | Забытая парольная фраза, файл ключа, стёртый вместе с сервером, который он защищал, никем не экспортированный заголовок LUKS | **Ничего.** Это единственная строка без столбца восстановления, и встречается она чаще, чем отказ железа |

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

Бэкап-цели нужны диск и адрес, а не ядра. Самый дешёвый второй сервер в другой юрисдикции — вполне достойная точка назначения, и единственная копия, которая переживёт инцидент у первого провайдера.

## Снапшот — это не бэкап, и ваш хостер тоже не бэкап

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

Здесь это различие важнее, чем у обычного хостера, потому что привычные страховочные сетки убраны намеренно. Никто не заходит на клиентские серверы, поэтому никто не заметит, что ваша задача бэкапа не выполняется с марта. К аккаунту не привязана личность, поэтому нет человеческого пути вида «докажите, кто вы, и мы восстановим». А удаление здесь по-настоящему необратимо: закончившийся баланс — это событие потери данных, а не биллинговое событие.

**Условие о 24 часах — это весь аргумент целиком.** На этой платформе данные удалённого сервера уничтожаются в течение суток, а диски криптографически стираются, а не форматируются. Здесь нет отмены удаления, нет тихого холодного хранилища, нет исхода поддержки в духе «мы нашли более старую копию» — потому что хранить её означало бы держать ваши данные после того, как вы попросили их убрать. Страховочная сетка и приватность — это одна и та же сделка, заключённая один раз.

## Правило 3-2-1, переписанное для тех, кто никогда не показывал документы

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

Перепишите правило как **три копии, два провайдера, две юрисдикции**. Сбои, разом уничтожающие обе копии, почти никогда не бывают физическими — это потерянный доступ к аккаунту, неудачная неделя у провайдера или судебный инструмент, который достаёт в одной стране и не дотягивается до другой. Два сервера в одной стойке — это одна копия с лишними телодвижениями; два сервера под одним правовым режимом немногим лучше. Наш [гайд по юрисдикциям](https://servhidden.com/ru/guides/choosing-an-offshore-jurisdiction) объясняет, как выбрать вторую так, чтобы она не повторяла риски первой.

На практике это дёшево. Бэкап-цели не нужны ядра, и сеть ей почти не нужна — нужны диск и адрес. Самый младший [тариф VPS](https://servhidden.com/ru/vps) в другой из наших [семи локаций](https://servhidden.com/ru/locations) — вполне достойная точка назначения для restic или Borg, а для архивов на терабайты [выделенный сервер](https://servhidden.com/ru/dedicated) с настоящими дисками обходится дешевле за терабайт, чем любое объектное хранилище. Там, где данных действительно много и читают их редко, экономика с большим отрывом на стороне «железа».

Одну вещь люди делают правильно для продакшена и неправильно для бэкап-цели: платить за неё так же. Второй сервер, купленный по карте на своё имя, незаметно возвращает личность, которую вы старались убрать с первого, и при этом теперь хранит полную копию всего, что на нём есть. Если продакшен-сервер оплачен [в Monero](https://servhidden.com/ru/guides/how-to-pay-for-hosting-with-monero), бэкап-сервер заслуживает того же обращения.

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

## Push, pull и ошибка, из-за которой одна плохая ночь съедает обе копии

Вот схема, которую почти все строят первой. Задача на продакшен-сервере запускается по ночам, хранит ключ или токен для бэкап-цели, подключается и отправляет данные (push). Это работает, это просто, и у этого есть свойство, которое становится видно только в худший день жизни сервера: **кто контролирует продакшен-машину, тот контролирует и бэкапы.**

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

Есть два чистых решения, и они хорошо сочетаются с [базовым хардненингом](https://servhidden.com/ru/guides/first-hour-vps-hardening-checklist), который вы уже должны были сделать.

- **Цель в режиме append-only.** Оба основных инструмента поддерживают режим, в котором клиент может добавлять данные, но не может их удалять. Borg делает это, закрепляя SSH-ключ на цели за borg serve --append-only; restic делает то же самое REST-сервером, запущенным с --append-only. Продакшен-сервер пишет каждую ночь и структурно не способен уничтожить историю. Удаление старых снапшотов происходит уже на стороне цели, в сессии, которую продакшен-машина начать не может.

- **Pull вместо push.** Разверните направление: бэкап-хост сам подключается к продакшену, читает и сохраняет. У продакшена вообще нет учётных данных для цели, поэтому красть нечего. Ограничьте ключ, который используется на стороне продакшена, директивой restrict и принудительной command=, чтобы украденный ключ бэкапа не превратился в шелл.

Pull — более надёжная модель и требует чуть больше работы для настройки; append-only почти ничего не стоит, если вы уже используете Borg или restic. Любой из этих вариантов превращает «атакующий удалил мои бэкапы» из результата в неудавшуюся попытку. Если вы возьмёте из этого гайда только одну мысль, пусть это будет она.

## Шифруйте на источнике, а затем решайте, кто держит ключ

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

Это другой механизм, чем шифрование собственного диска сервера, и они отвечают на разные вопросы — наш гайд про [полное шифрование диска на VPS](https://servhidden.com/ru/guides/full-disk-encryption-on-a-vps) разбирает, что шифрование диска защищает, а что нет, пока машина работает. Шифрование бэкапа — более простой и более ценный из двух вариантов, потому что модель угроз здесь честная: данные лежат в покое, на железе, которое вы не контролируете, а ключ туда никогда не попадает.

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

- Храните парольную фразу на сервере только как файл, читаемый исключительно root, на который ссылаются через --password-file, чтобы она никогда не попадала в список процессов или историю шелла.

- Храните человекочитаемую копию вне всех задействованных машин. Бумажка в ящике стола действительно надёжнее менеджера паролей, синхронизирующегося с аккаунтом, доступ к которому вы тоже можете потерять.

- Добавьте в репозиторий второй ключ — командой restic key add или экспортированным ключом Borg — чтобы одна забытая парольная фраза была неудобством, а не концом архива.

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

## Выбор инструмента одной таблицей

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

| Инструмент | Шифрует перед отправкой | Дедупликация | Цель append-only | Где применим |
| --- | --- | --- | --- | --- |
| **restic** | Да, весь репозиторий | Да | Да, через собственный REST-сервер | Выбор по умолчанию. Говорит по SFTP, с объектным хранилищем и собственным сервером, поэтому целью может быть почти что угодно |
| **BorgBackup** | Да, весь репозиторий | Да, лучшая в группе | Да, нативно через SSH | Одна Linux-цель, доступная по SSH. Не знает равных, когда данных много и они повторяются |
| **rsync с ротацией** | Нет — цель видит всё | Частичная, через hardlinks | Нет | Зеркалирование на машину, которую вы полностью контролируете, когда мгновенное частичное восстановление важнее приватности |
| **rclone** | Только с rclone crypt | Нет | Зависит от провайдера хранилища | Перенос уже существующего архива в объектное хранилище или между провайдерами |
| **Репликация ZFS** | Только с зашифрованным датасетом | Да, на уровне блоков | Через права на снапшоты | Репликация между двумя машинами ZFS. Очень быстро, очень жёстко к обоим концам |
| **tar с age или GPG** | Да, если шифруете сам архив | Нет | Неприменимо | Небольшие, редкие, вечные архивы, где простота важнее эффективности |

Для одного сервера restic на второй VPS — самый короткий путь к правильному решению. Для сидбокса, медиаархива или чего угодно с множеством похожих крупных файлов дедупликация Borg — это разница между забитым диском и комфортным; [гайд по сидбоксу](https://servhidden.com/ru/guides/seedbox-setup-guide) подробнее разбирает сторону хранения для такой нагрузки.

## Всё, что запущено, — это не файл

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

Три выхода, в порядке возрастания усилий. Сделать дамп: mysqldump --single-transaction даёт согласованный дамп InnoDB без блокировки записывающих процессов, а pg_dump делает то же самое для PostgreSQL. Снять снапшот: заморозить файловую систему или сделать снапшот LVM или ZFS, скопировать из снапшота, освободить его — так поступают с наборами данных, слишком большими для ночного дампа. Или остановить: для небольшого сервиса две минуты простоя в 04:00 — вполне достойная стратегия консистентности, и единственная, у которой нет краевых случаев.

Та же логика касается не только баз данных. Записываемый слой контейнера одноразовый, а вот его тома — нет, как и лежащий рядом файл docker compose с окружением: бэкап, который восстанавливает данные, но не определение, оставляет вас пересобирать стек по памяти. Очереди сообщений, Redis с включённой персистентностью и почтовый спул, в который пишет MTA, заслуживают того же отношения: заморозить, снять снапшот или сделать дамп, но никогда не копировать напрямую в надежде на лучшее.

## Что бэкапить и что все забывают

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

- /etc целиком, плюс юниты и таймеры systemd, которые вы написали, и любые crontab, лежащие вне него.

- Сертификаты TLS и их приватные ключи, или как минимум ключ аккаунта ACME, чтобы сертификаты продлевались, а не начинались с нуля.

- Правила файрвола и список пакетов, которые вместе восстанавливают облик машины быстрее, чем любая память о нём.

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

- DNS-записи, экспортированные в текст, включая обратные записи и записи PTR, которые живут у провайдера, а не на сервере.

**Некоторые ключи — это не данные, а идентичность.** Приватный ключ onion-сервиса Tor *и есть* адрес: потеряйте его — и сайт не сможет вернуться под тем же [.onion-именем](https://servhidden.com/ru/guides/how-to-host-a-tor-hidden-service), что бы ещё вы ни восстановили. Серверный ключ WireGuard означает переиздание всех клиентских конфигураций, которые вы когда-либо раздали. Ключ DKIM почтового сервера означает новый селектор и старт репутации [доставляемости](https://servhidden.com/ru/guides/offshore-mail-server-setup) с нуля. Seed и состояние каналов ноды Lightning могут означать средства, а не файлы — [гайд по хостингу нод](https://servhidden.com/ru/guides/crypto-node-hosting-guide) прямо об этом говорит. Копируйте их отдельно, храните офлайн и считайте ценнее, чем данные, которые они защищают.

## Непроверенное восстановление — это слух

Программа для бэкапов отчитывается сама о себе, и отчитывается она честно, но не о том, что важно. «Снапшот завершён» означает, что данные записаны в репозиторий. Это ничего не говорит о том, можно ли прочитать этот репозиторий на другой машине, человеком, который не помнит, что он настраивал одиннадцать месяцев назад.

Начните с дешёвых проверок целостности — restic check --read-data-subset=5% или borg check --verify-data по расписанию — и помните, что они проверяют архив, а не вашу способность им воспользоваться. Настоящая тренировка устроена иначе и занимает один день, один раз. Закажите свежий сервер с почасовой оплатой в локации, которую вы обычно не используете. Разверните бэкап, имея только адрес репозитория, парольную фразу и собственные заметки. Поднимите сервис. Засеките время всего процесса. Затем уничтожьте машину. Итоговая стоимость — несколько долларов, и это единственное упражнение, дающее цифру, которой можно доверять.

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

Запишите два числа, которые даёт тренировка: сколько заняло восстановление и сколько работы может потерять ваше расписание. Это и есть политика бэкапов. Всё, что было сказано выше, — детали реализации на службе у этих двух чисел.

## Автоматизация, чтобы это продолжало происходить

Запускайте задачу через таймер systemd, а не через cron. Так вы получаете логи в одном месте, реальную запись о последнем запуске и расписание, переживающее перезагрузки — ничего из этого cron без лишней работы не даёт. Держите парольную фразу вне самого юнит-файла, который любой с доступом к шеллу может прочитать прямо через systemctl cat.

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

Настраивайте глубину хранения осознанно, а не по умолчанию. Что-то вроде --keep-daily 7 --keep-weekly 4 --keep-monthly 6 покрывает и ошибки, которые вы заметите сегодня ночью, и порчу данных, которую вы заметите весной, не разрастаясь бесконечно. Запускайте удаление старых копий на стороне цели, если вы перешли на append-only, — в этом весь смысл перехода на append-only. Объём передачи редко становится ограничением в нашей сети — трафик безлимитен на любом тарифе, — поэтому планируйте расписание ради стабильности, а не ради квоты, и сверяйте время с собственными тихими часами. Более широкие привычки вокруг всего этого разобраны в [гайде по опсеку сервера](https://servhidden.com/ru/guides/server-opsec-staying-anonymous).

## Краткая версия

Если вы не сделаете с этой страницей больше ничего, сделайте эти шесть вещей, примерно в таком порядке:

- Разместите одну копию у второго провайдера, во второй юрисдикции, оплаченную так же приватно, как и первая.

- Сделайте эту копию append-only или забирайте её с цели через pull, чтобы скомпрометированный сервер не мог её уничтожить.

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

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

- Бэкапьте ключи идентичности отдельно — onion, WireGuard, DKIM, seed ноды, — потому что их нельзя сгенерировать заново.

- Один раз разверните бэкап на одноразовом сервере, засеките время и запишите, чего не хватило.

Ничего из этого не экзотика, и ничего не займёт выходные. Это один вечер настройки и одна тренировка — против категории потерь, которая закрывает проекты. На платформе, которая намеренно ничего о вас не хранит, копия, которую вы сделали сами, — единственная, что существует, и это справедливая цена такого устройства. [Разверните второй сервер](https://servhidden.com/ru/vps) в юрисдикции, отличной от первой, и дайте сегодняшнему бэкапу куда приземлиться.





FAQ

## Бэкап VPS — частые вопросы





### 01
Делает ли ServHidden бэкап моего VPS?



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





### 02
Снапшот — это то же самое, что бэкап?



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





### 03
restic или BorgBackup — что выбрать?



restic — если целью может стать объектное хранилище, SFTP или что-то ещё не выбранное, потому что он понимает больше всего типов хранилищ. BorgBackup — если цель это одна Linux-машина по SSH, а данных много и они повторяются, потому что его дедупликация сильнейшая в группе. Оба шифруют на источнике до того, как что-либо покинет машину, и оба поддерживают режим append-only, а это важнее самого выбора между ними.





### 04
Как не дать атакующему удалить мои бэкапы?



Убирайте возможность, а не мотив. Либо сделайте цель append-only, чтобы учётные данные на продакшен-сервере могли добавлять данные, но никогда их не удаляли, либо разверните соединение так, чтобы бэкап-хост сам забирал данные с продакшена (pull), а на продакшене вообще не было учётных данных. Удаление бэкапов до того, как заявить о себе, — стандартная практика для тех, кто занимается этим на коммерческой основе, а копия, которую может удалить атакующий, — это не вторая копия.





### 05
Где должна храниться вторая копия бэкапа?



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





### 06
Как часто нужно делать бэкап?



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





### 07
Безопасно ли хранить зашифрованный бэкап на сервере, который я не контролирую?



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





### 08
Что будет, если я потеряю парольную фразу от бэкапа?



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




Похожие руководства

## Читайте также


[### Как выбрать офшорную юрисдикцию для хостинга в 2026 году

Перед покупкой


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/choosing-an-offshore-jurisdiction)
[### VPS против выделенного сервера для задач с требованиями к конфиденциальности

Перед покупкой


Когда VPS достаточен, когда общая аренда становится уязвимостью, а когда bare metal — единственный честный ответ. Аппаратная изоляция, риски гипервизора и соотношение цены и модели угроз.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/vps-vs-dedicated-for-privacy)
[### Собственный VPN на VPS без KYC: WireGuard против OpenVPN

Эксплуатация


Почему собственный VPN превосходит коммерческих провайдеров, и как WireGuard и OpenVPN реально сравниваются по конфиденциальности, производительности и операционным рискам в 2026 году.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 для AI-инференса (и где помещается RTX 5090)

Перед покупкой


Руководство по выбору GPU: какая NVIDIA GPU подходит для self-хостируемых LLM, изображений, видео, голоса и файнтюнинга в 2026 году. RTX 4090 vs RTX 5090 vs H100 SXM5 vs двойной H100 — VRAM, пропускная способность, $/токен, когда каждый из них выигрывает.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/rtx-4090-vs-h100-for-ai-inference)
[### Офшорный Windows RDP для форекс-трейдинга MT4 / MT5 / cTrader

Эксплуатация


Полное руководство: зачем нужен Windows RDP для форекс-трейдинга, как выбрать офшорную юрисдикцию с низкой латентностью, настройка MT4 / MT5 / cTrader / Expert Advisor, латентность до брокерских серверов и путь no-KYC чекаута.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/offshore-windows-rdp-for-forex-trading)
[### Хостинг с игнорированием DMCA: что это реально означает в 2026 году

Перед покупкой


Что на самом деле даёт хостинг с «игнорированием DMCA», какие юрисдикции действительно его поддерживают, для каких задач он нужен и какие авторско-правовые ловушки этот термин не покрывает.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/dmca-ignored-hosting-explained)
[### Анонимная регистрация домена за криптовалюту: WHOIS-приватность в 2026 году

Конфиденциальность


Практическое руководство 2026 года по регистрации доменов без раскрытия личности: режимы WHOIS по TLD, выбор регистратора, варианты оплаты криптовалютой и операционные ошибки, которые всё равно вас раскроют.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/anonymous-domain-registration-with-crypto)
[### Криптоплатежи за хостинг: Monero против Bitcoin против USDT

Конфиденциальность


Как выбор монеты влияет на то, что провайдер узнаёт о вас. Конфиденциальность, комиссии, финальность и уязвимость к анализу блокчейна для XMR, BTC и USDT — с чёткой рекомендацией.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Действительно ли офшорный хостинг анонимен? Честный ответ

Конфиденциальность


Офшорный хостинг без KYC избавляет от идентификации, которую собирает обычный провайдер, — но «анонимность» зависит от способа оплаты, логирования у провайдера и Вашей собственной opsec-дисциплины. Вот что на самом деле можно отследить.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/is-offshore-hosting-truly-anonymous)
[### Первый час защиты VPS: чек-лист

Эксплуатация


Конкретный, последовательный чек-лист для защиты нового VPS менее чем за час: SSH-ключи, файрвол, fail2ban, автоматические обновления и сокращение поверхности атаки, которое останавливает большинство оппортунистических атак.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/first-hour-vps-hardening-checklist)
[### Что такое хостинг без KYC? Определение, законность и принцип работы

Конфиденциальность


Хостинг без KYC позволяет арендовать сервер без какой-либо проверки личности — без имени, электронной почты и документов. Здесь подробно объясняется, что это означает, как работает технически, законно ли это и как выбрать надёжного провайдера.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/what-is-no-kyc-hosting)
[### Законен ли офшорный хостинг? Честный ответ 2026 года

Перед покупкой


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/is-offshore-hosting-legal)
[### Как оплатить хостинг через Monero (XMR) — пошаговое руководство

Конфиденциальность


Пошаговое руководство по оплате VPS или выделенного сервера с помощью Monero (XMR): почему XMR — наиболее приватный вариант, как его приобрести и как работает оформление заказа — от выставления счёта до запуска сервера за считанные минуты.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-pay-for-hosting-with-monero)
[### Как анонимно разместить сайт — практическое руководство 2026

Конфиденциальность


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-host-a-website-anonymously)
[### Как настроить WireGuard VPN на VPS — пошаговое руководство

Эксплуатация


Создайте собственный приватный VPN на VPS с помощью WireGuard: почему самостоятельный хостинг надёжнее коммерческих решений, полная инструкция от установки до подключения клиента, а также советы по укреплению безопасности.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Как самостоятельно разместить LLM на GPU-сервере — руководство 2026 года

Эксплуатация


Запустите собственную большую языковую модель на арендованном GPU-сервере: почему самостоятельный хостинг превосходит API, какой GPU и модель выбрать, настройка с Ollama или vLLM и стоимость.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof-хостинг против офшорного хостинга — в чём разница?

Перед покупкой


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/bulletproof-vs-offshore-hosting)
[### Как купить VPS за Bitcoin — пошаговая инструкция (2026)

Перед покупкой


Понятное руководство для начинающих: как купить VPS за Bitcoin — получить BTC, выбрать тариф, оплатить счёт и запустить сервер без банковской карты и без привязки личных данных.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-buy-a-vps-with-bitcoin)
[### Лучшие страны для хостинга, игнорирующего DMCA, в 2026 году

Перед покупкой


Где размещать серверы, недосягаемые для американских требований о снятии контента: юрисдикции, которые реально работают, что на самом деле означает «игнорирование DMCA» и как сделать правильный выбор.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/best-countries-for-dmca-ignored-hosting)
[### Как разместить скрытый сервис Tor (сайт .onion) — руководство 2026 года

Эксплуатация


Настройте onion-сервис Tor на VPS: что такое скрытый сервис, почему это наиболее надёжная форма анонимного хостинга, полная инструкция по настройке и способы сохранить реальную анонимность.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/how-to-host-a-tor-hidden-service)
[### Настройка офшорного почтового сервера — самостоятельный хостинг частной почты в 2026 году

Эксплуатация


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/offshore-mail-server-setup)
[### Руководство по хостингу криптонод — запустите блокчейн-ноду на VPS

Эксплуатация


Как разместить блокчейн-ноду на сервере: зачем запускать собственную ноду, как подобрать конфигурацию для Bitcoin, Ethereum, Monero и других сетей, настройка и обеспечение конфиденциальности.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/crypto-node-hosting-guide)
[### GPU-хостинг для Stable Diffusion — запустите собственный сервер генерации изображений

Эксплуатация


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


FAQ из 6 вопросов](https://servhidden.com/ru/guides/gpu-hosting-for-stable-diffusion)
[### OpSec сервера — Как оставаться анонимным при управлении сервером

Конфиденциальность


Операционная безопасность для тех, кто управляет анонимным сервером: ошибки, которые раскрывают личность, привычки, которые их предотвращают, и способы по-настоящему разделить идентичности.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/server-opsec-staying-anonymous)
[### Руководство по настройке сидбокса — создайте собственный приватный сидбокс в 2026 году

Эксплуатация


Как развернуть собственный сидбокс на сервере: что такое сидбокс, как подобрать конфигурацию, установить торрент-клиент с веб-интерфейсом и обеспечить приватность и безопасность.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/seedbox-setup-guide)
[### Как обойти DPI-цензуру с помощью собственного VPS (гайд 2026)

Конфиденциальность


Ваш VPN перестал работать? Как обойти DPI-цензуру с помощью собственного VPS: что на самом деле обнаруживает глубокая инспекция пакетов, какой из пяти протоколов 2026 года побеждает какую блокировку, и полное пошаговое руководство по VLESS+REALITY.


FAQ из 6 вопросов](https://servhidden.com/ru/guides/bypass-dpi-censorship-with-your-own-vps)
[### Полнодисковое шифрование на VPS: LUKS и что оно реально защищает

Эксплуатация


Как зашифровать VPS с помощью LUKS: тома данных, полное шифрование корня с удалённой разблокировкой по SSH, параметры для небольшого сервера и честный разбор того, от чего защищает шифрование диска.


FAQ из 8 вопросов](https://servhidden.com/ru/guides/full-disk-encryption-on-a-vps)
[### Скрытие IP исходного сервера: CDN, обратный прокси и утечки

Конфиденциальность


Ставить ли CDN перед офшорным сервером: что он скрывает, какой канал для жалоб вы получаете взамен, шесть способов утечки исходного IP и как проверить свой.


FAQ из 8 вопросов](https://servhidden.com/ru/guides/hiding-your-origin-server-ip)
[### Свой сервер Matrix: федерация, метаданные и что не скрывает E2EE

Эксплуатация


Что даёт свой сервер Matrix на практике: Synapse против Conduit, server_name, который нельзя изменить, диск, который съедает медиатека, и что раскрывает федерация.


FAQ из 8 вопросов](https://servhidden.com/ru/guides/self-host-a-matrix-server)
[### Как перенести сайт на офшорный хостинг без простоя

Эксплуатация


Порядок, который делает миграцию хостинга скучной: снизьте DNS TTL заранее, держите оба сервера параллельно, замораживайте запись на минуты, а не часы, — и подчистите след из пассивного DNS, Certificate Transparency и WHOIS, который оставляет переезд.


FAQ из 8 вопросов](https://servhidden.com/ru/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Эксплуатация


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ из 8 вопросов](https://servhidden.com/ru/guides/self-host-a-crypto-payment-gateway)




## Дайте сегодняшнему бэкапу куда приземлиться



Семь юрисдикций, безлимитный трафик на каждом тарифе и серверы от $7.50/мес — достойная точка назначения для restic или Borg. Без KYC, без e-mail, только крипта — и для бэкап-цели, и для продакшена.


[Тарифы VPS](https://servhidden.com/ru/vps)
[Выделенные серверы](https://servhidden.com/ru/dedicated)
[Все локации](https://servhidden.com/ru/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "Офшорные VPS и выделенные серверы в 7 юрисдикциях. Без KYC, без логов, только криптовалюта. Приватность — не функция, а архитектура.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Бэкап VPS: шифрование, второй провайдер, проверенное восстановление",
    "description": "Хостер не хранит бэкапы. Что убивает серверы, почему push-бэкап умирает вместе с сервером, restic против Borg, забытые ключи и как проверить восстановление на практике.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "ru",
    "keywords": "бэкап VPS, резервное копирование VPS сервера, restic vs BorgBackup, шифрование бэкапа VPS, бэкап VPS без KYC, правило 3-2-1 резервного копирования, защита бэкапов от шифровальщика, как восстановить сервер из бэкапа",
    "articleSection": "Эксплуатация",
    "wordCount": 3503
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Делает ли ServHidden бэкап моего VPS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Нет, и это осознанное решение, а не упущение. Наша политика хранения прямо говорит: бэкапы не хранятся, данные сервера уничтожаются в течение 24 часов после удаления, а диски криптографически стираются, а не форматируются. Хранить копию ваших данных после того, как вы попросили их удалить, противоречило бы самой причине существования платформы. Всё, что вы хотите сохранить после потери сервера, должны скопировать вы сами — в идеале ко второму провайдеру во второй юрисдикции."
            }
        },
        {
            "@type": "Question",
            "name": "Снапшот — это то же самое, что бэкап?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Нет. У снапшота с сервером, с которого он снят, общий любой домен отказа — тот же провайдер, тот же аккаунт, та же страна, часто то же хранилище. Он отлично откатывает неудачное обновление и бесполезен при потере аккаунта, провайдера или самой машины. Считайте снапшот кнопкой отмены, а бэкап — страховкой: они решают разные задачи, и нужны обе."
            }
        },
        {
            "@type": "Question",
            "name": "restic или BorgBackup — что выбрать?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "restic — если целью может стать объектное хранилище, SFTP или что-то ещё не выбранное, потому что он понимает больше всего типов хранилищ. BorgBackup — если цель это одна Linux-машина по SSH, а данных много и они повторяются, потому что его дедупликация сильнейшая в группе. Оба шифруют на источнике до того, как что-либо покинет машину, и оба поддерживают режим append-only, а это важнее самого выбора между ними."
            }
        },
        {
            "@type": "Question",
            "name": "Как не дать атакующему удалить мои бэкапы?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Убирайте возможность, а не мотив. Либо сделайте цель append-only, чтобы учётные данные на продакшен-сервере могли добавлять данные, но никогда их не удаляли, либо разверните соединение так, чтобы бэкап-хост сам забирал данные с продакшена (pull), а на продакшене вообще не было учётных данных. Удаление бэкапов до того, как заявить о себе, — стандартная практика для тех, кто занимается этим на коммерческой основе, а копия, которую может удалить атакующий, — это не вторая копия."
            }
        },
        {
            "@type": "Question",
            "name": "Где должна храниться вторая копия бэкапа?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "У другого провайдера, в другой юрисдикции, оплаченная так же приватно, как продакшен-сервер. События, уничтожающие обе копии разом, редко бывают физическими — это потерянный доступ к аккаунту, неудачная неделя у провайдера или судебный инструмент, работающий в одной стране и бессильный в другой. Два сервера в одной стойке — это одна копия с лишними телодвижениями. Поскольку инструменты шифруют на источнике, второй хост не обязан быть тем, кому вы доверяете."
            }
        },
        {
            "@type": "Question",
            "name": "Как часто нужно делать бэкап?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Отталкивайтесь от того, сколько работы вы готовы переделать. Блог может потерять день, и никто не заметит; магазин не может потерять час заказов. Для большинства односерверных конфигураций по умолчанию подходит ежедневный бэкап, а дампы базы данных — чаще, если записи ценны. Важнее частоты глубина хранения: порчу данных часто замечают спустя недели, так что храните историю достаточно глубоко, чтобы вернуться к точке до её начала."
            }
        },
        {
            "@type": "Question",
            "name": "Безопасно ли хранить зашифрованный бэкап на сервере, который я не контролирую?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Что касается содержимого — да: restic и Borg шифруют данные до того, как они покинут источник, поэтому цель хранит блоки, которые не может прочитать, а ключ никуда не передаётся. Что цель всё же узнаёт — это метаданные: примерный объём данных, как они меняются и когда запускаются задачи. Обычно это приемлемо. Если нет — меняйте расписание и держите репозиторий на машине, чьё владение не связано с продакшен-сервером."
            }
        },
        {
            "@type": "Question",
            "name": "Что будет, если я потеряю парольную фразу от бэкапа?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Архив пропадает безвозвратно, и никто не сможет вам помочь. Это самая частая полная потеря во всей этой теме и единственный сбой без пути к восстановлению. Храните парольную фразу отдельно от всех задействованных машин, отдавайте предпочтение бумаге, а не аккаунту, доступ к которому вы тоже можете потерять, и добавьте в репозиторий второй ключ, чтобы один забытый пароль был просто неудобством, а не концом архива."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Главная",
            "item": "https://servhidden.com/ru/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Руководства по приватному хостингу",
            "item": "https://servhidden.com/ru/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Бэкап VPS: шифрование, второй провайдер, проверенное восстановление",
            "item": "https://servhidden.com/ru/guides/vps-backup-strategy"
        }
    ]
}
```