VDS · Резервные копии и диск

Копии на другой площадке

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

Обновлено 23 августа 2026 г.

Копия на том же диске защищает ровно от одного случая — от вашей же ошибки rm -rf. От переустановки системы, потери доступа, шифровальщика и любой аварии, затрагивающей машину целиком, спасает только копия в другом месте.

Куда увозить

КудаПлюсыНа что обратить внимание
Вторая VDSПолный контроль, быстрый каналОбе машины у одного поставщика — общий риск
Домашний компьютер или NASДёшево, физически отдельноНужен постоянный адрес или инициатива со стороны дома
Объектное хранилище S3Не требует обслуживания, платите за объёмПроверьте стоимость исходящего трафика при восстановлении
Отдельное хранилище с доступом по SFTPПросто, дёшево при больших объёмахОбычно нет версий на стороне хранилища

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

Кто кого забирает

Есть два варианта, и они по-разному защищают от шифровальщика.

Машина отправляет копию. Просто, но ключ отправки лежит на машине. Взломщик, получивший root, дотянется и до хранилища.

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

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

command="rrsync -wo /srv/backup/vds",restrict ssh-ed25519 AAAA... vds-backup

С Restic ту же роль играет режим append-only — репозиторий, в который можно только дописывать:

restic --repo sftp:backup@host:/srv/restic backup /data

Удаление старых снимков в этом случае выполняет приёмник по своему расписанию, а не машина.

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

Проверка доступности

Восстановление обычно нужно в худший момент: машина недоступна, паника, времени нет. Заранее убедитесь, что у вас есть:

  • Адрес хранилища и учётные данные — записанные вне этой машины.
  • Пароль репозитория Restic — в менеджере паролей.
  • Пароль root машины — он хранится зашифрованным и показывается по кнопке во вкладке «Доступ» панели /hosting/vds/<id>, но панель доступна только вам.
  • Список того, что где лежит: какая копия что содержит.

Пропишите это в короткой заметке и держите её не на VDS.

Сколько данных увозить

Полоса до 500 Мбит/с, но узкое место обычно на стороне приёмника. Первую полную копию делайте вручную и в спокойное время, дальше пойдут только изменения. Ограничить скорость, чтобы не мешать сервисам:

rsync --bwlimit=10000 ...
restic backup --limit-upload 10000 ...

Значения в килобайтах в секунду.

Частые ошибки

  • Обе копии у одного поставщика в одном месте. Это одна площадка, как её ни называй.
  • Копия отправляется, но никто не знает, что она перестала отправляться. Настройте push-проверку в Uptime Kuma.
  • Восстановление ни разу не пробовали. См. учебное восстановление.
  • Учётные данные хранилища — в скрипте, который тоже попадает в копию. Не смертельно при шифровании, но при потере хранилища вместе со скриптом это дыра.

Что именно класть в копию — в статье что нужно копировать, способы — rsync и Restic.