Как настроить удаленный VPS для резервных копий

Что на самом деле представляет собой удаленное хранилище резервных копий

Удаленное хранилище резервных копий — это отдельный сервер, на котором хранится копия ваших данных и который выходит из строя независимо от основного. VPS у другого провайдера — самый доступный вариант для большинства пользователей. Существует три реалистичных сценария: использование Proxmox Backup Server на VPS, репозиторий restic, доступный по SSH или S3, либо rsync-зеркало, которое забирает хост резервного копирования. Выбор зависит от того, что именно вы восстанавливаете и насколько быстро вам нужен доступ к данным. Вопрос о том, кто имеет право удалять копию, определяет остальные параметры.

«Удаленное» означает другой домен отказа. Это подразумевает другого провайдера и учетную запись, которая не использует общие данные для входа с той, где работает ваш основной сервер. Второй сервер в другом регионе того же провайдера переживет пожар в одном здании. Однако он не защищен от взлома учетной записи панели управления, так как одна учетная запись контролирует обе копии.

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

Какой из трех вариантов вам подходит

• Proxmox Backup Server (PBS): источником является Proxmox VE (виртуальная среда), а восстанавливаемым объектом — целая виртуальная машина. Резервное копирование выполняется на уровне образов дисков, а задачи проверки (verify jobs) повторно считывают данные, размещенные на целевом хранилище.
• Репозиторий restic: источником является один или несколько Linux-хостов, а восстанавливаемым объектом — каталог или дамп базы данных. Шифрование происходит на стороне клиента, поддерживаются протоколы SSH и S3, а также собственный REST-протокол.
• rsync через SSH с вытягиванием (pull) на хост резервного копирования: вам нужно, чтобы файлы на целевом сервере хранились как обычные файлы, доступные для чтения через ls и cat, без необходимости использования клиентского ПО для их восстановления.

Если вы не можете определиться, используйте restic. Он шифрует данные до того, как они покинут машину, и не требует на целевом сервере ничего, кроме SSH-аккаунта и дискового пространства. В Настройка резервного копирования restic на VPS клиентская часть рассмотрена более подробно, а в Сравнение restic и BorgBackup описан выбор, если вы уже используете Borg.

Оценка объема хранилища: во сколько обойдется месяц хранения

Дедупликация — причина, по которой итоговые цифры оказываются меньше ожидаемых. И restic, и PBS разбивают файлы на фрагменты переменного размера и вычисляют хеш для каждого из них. Каждый уникальный фрагмент сохраняется только один раз. Второе резервное копирование набора данных объемом 500 GB не добавляет еще 500 GB. Оно добавляет только те фрагменты, которые изменились.

Таким образом, размер репозитория зависит от возраста самого старого снимка, а не от количества снимков. Возьмем 500 GB данных и 5 GB новых уникальных данных в день. В этом случае репозиторий будет содержать базовые 500 GB плюс примерно 5 GB за каждый день вплоть до самого старого снимка, который сохраняет политика ротации.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Столбец в долларах оценивает стоимость такого репозитория из расчета 10 долларов США за TB в месяц. Это значение приведено для примера, чтобы показать расчеты, а не как реальное предложение от какого-либо провайдера; подставьте актуальную цену за TB для тарифа, который вы рассматриваете. Неделя ежедневных резервных копий занимает около 535 GB. Полный год истории занимает 2,325 GB, что составляет $23.25 в месяц против $5.35 за неделю. История стоит дешево. Вы платите в основном за базовую копию данных.

Дедупликация не дает эффекта для данных, которые поступают уже сжатыми или зашифрованными. Дамп базы данных в формате gzip при каждом запуске меняется полностью, поэтому каждый дамп записывается как набор новых фрагментов, и репозиторий увеличивается на полный размер дампа каждую ночь. Записывайте дамп без сжатия и позвольте инструменту резервного копирования сжать его, так как restic поддерживает сжатые репозитории начиная с версии 0.14, а в версии 0.19 были добавлены режимы fastest и better zstd. Фото- и видеоархивы плохо поддаются дедупликации по той же причине, поэтому оценивайте их объем исходя из реальной скорости роста, а не по приведенным выше строкам.

В данном случае вы платите за простаивающий диск, а не за CPU, и это именно та ситуация, когда storage VPS выгоднее обычного VPS.

Почему пропускная способность и время восстановления определяют выбор плана

Дисковое пространство стоит недорого. Основные затраты приходятся на первую выгрузку данных и последующее восстановление. 500 GB — это 4 триллиона бит, поэтому деление на скорость канала дает минимально возможное время полного восстановления.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Это теоретические показатели скорости линии без учета накладных расходов протоколов, поэтому рассматривайте их как идеальный сценарий. При скорости 100 Mbit/s для полного восстановления потребуется 11.1 часов, прежде чем данные станут доступны для работы. При домашнем исходящем канале 40 Mbit/s потребуется 27.8 часов. На порту 1 Gbit/s то же восстановление займет 1.1 часов. Множество мелких файлов обрабатываются медленнее, чем показывает расчет, так как при размере файлов менее нескольких сотен килобайт доминируют накладные расходы на каждый файл.

Из этого следуют два вывода. Если ваш целевой показатель времени восстановления (RTO), то есть допустимое время простоя, составляет четыре часа, то восстановление 500 GB через канал 100 Mbit/s уже не укладывается в этот лимит, и более дешевый диск здесь не поможет. Кроме того, большинство VPS-планов ограничивают исходящий трафик, поэтому одно полное восстановление израсходует 0.5 TB из месячной квоты хостинга резервных копий. Проверьте эту квоту и узнайте, что делает провайдер при её превышении, до того, как данные вам понадобятся.

Первое резервное копирование включает весь набор данных и является самым медленным процессом, который вам предстоит выполнить. Запустите его в пятницу и ограничьте скорость, чтобы не забить исходящий канал источника: restic использует --limit-upload в KiB в секунду, rsync использует --bwlimit.

Вариант 1: Proxmox Backup Server как удаленное хранилище данных

PBS подходит, если источником является Proxmox VE, а единицей восстановления — виртуальная машина. VPS не может загрузиться с ISO-образа Proxmox, поэтому устанавливайте PBS поверх Debian. Версия 4.2 является актуальной на август 2026 года и базируется на Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Сравните эту контрольную сумму со значением, опубликованным на странице репозиториев пакетов Proxmox. Репозиторий apt надежен ровно настолько, насколько надежен ключ, который вы проверили. Затем выполните /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Выделите для хранилища данных (datastore) отдельную файловую систему или отдельный том. Переполнение хранилища останавливает резервное копирование, а хранилище, использующее общую корневую файловую систему, выводит из строя весь сервер при заполнении.

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

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Секрет токена отображается только один раз и не может быть прочитан повторно, поэтому сохраните его сразу при появлении. Роль имеет такое же значение, как и сам токен. DatastoreBackup может создавать и восстанавливать собственные резервные копии, при этом токен не обладает привилегией Datastore.Prune, поэтому он не может удалить уже записанный снимок.

Политика хранения в PBS состоит из двух частей, и вторую часть часто пропускают. Prune удаляет снимки. Garbage collection удаляет фрагменты данных (chunks), на которые не ссылается ни один сохранившийся снимок. Свободное место появляется после garbage collection, а не после prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Запустите --dry-run, как только список снимков, которые планируется удалить, будет выглядеть корректно. Garbage collection выполняется в два этапа: сначала обновляется время доступа для каждого фрагмента, на который есть ссылки, затем удаляются фрагменты, время доступа к которым старше порогового значения (24 часа и 5 минут до начала запуска). Этот льготный период существует для того, чтобы фрагмент, записываемый текущим процессом резервного копирования, не был удален в процессе работы. Настройте ежедневный запуск prune и еженедельный garbage collection для хранилища данных, а также добавьте задачу проверки (verify job), чтобы целевой сервер перечитывал свои фрагменты и сообщал о повреждении данных на диске до того, как это обнаружится при восстановлении.

Если источником является другой экземпляр PBS, удаленный сервер может забирать данные (pull) вместо того, чтобы принимать их (push).

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Запустите эту задачу синхронизации на VPS, используя стандартное направление pull. VPS подключается к домашнему хранилищу данных, что означает, что на домашнем сервере не хранятся учетные данные, способные получить доступ к удаленной копии.

Вариант 2: репозиторий restic по SSH или S3

В Debian и Ubuntu есть пакеты restic, но они отстают от основной версии. Версия 0.19.1 является актуальной на август 2026 года. Установите официальный бинарный файл на исходном хосте.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version выводит версию и версию компилятора Go, с помощью которого она была собрана. Для последующих обновлений используйте sudo restic self-update; это работает с официальными бинарными файлами, но не с копией, установленной через apt.

На сервере резервного копирования создайте учетную запись, которая не владеет никакими другими данными, затем скопируйте публичный ключ исходного хоста в /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Инициализируйте репозиторий с исходного хоста по протоколу SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

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

Управление хранением (retention) выполняется одной командой, вторая часть которой освобождает место на диске.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget удаляет снимки (snapshots). prune удаляет файлы пакетов (pack files), на которые ссылались только эти снимки, а --prune запускает этот процесс автоматически, если что-то было действительно удалено. Без этого параметра размер репозитория никогда не уменьшится. restic check проверяет структуру репозитория, а --read-data-subset=10% повторно считывает и вычисляет хеши для десятой части файлов пакетов, что позволяет обнаружить повреждения на целевом сервере без необходимости считывать все данные целиком. Другой вариант, --read-data-subset=1/10, проверяет одну фиксированную десятую часть, поэтому увеличение этого первого числа каждую неделю позволит проверить весь репозиторий за десять недель.

Если процесс был принудительно завершён, следующий запуск остановится с ошибкой repository is already locked exclusively by PID. Убедитесь, что резервное копирование не выполняется, затем очистите блокировку командой restic unlock.

Для объектного хранилища строка репозитория принимает вид s3:https://s3.example.net/web1, а учётные данные указываются в AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY. Всё остальное остаётся идентичным; именно так restic взаимодействует с самостоятельно развёрнутым объектным хранилищем MinIO, работающим на том же VPS.

Схема 3: rsync через SSH с ключом только для чтения

Свойство безопасности этой схемы заключается в направлении передачи. Резервный VPS подключается к источнику и считывает данные. У источника нет ключа и маршрута к хосту резервного копирования, поэтому взлом источника не позволит получить доступ к резервным копиям.

Создайте пару ключей на резервном VPS, затем установите открытую часть на источнике с принудительной командой.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync поставляется в составе пакета rsync по пути /usr/bin/rrsync в Debian 13 и Ubuntu 24.04. -ro разрешает только чтение и подразумевает -no-del, поэтому этот ключ не может записывать данные на источник или удалять что-либо на нем. restrict отключает функции SSH, которые здесь не нужны, включая перенаправление портов и pty, поэтому ключ нельзя использовать для интерактивного входа. Пути при этом становятся относительными к указанной вами директории, поэтому удаленный путь / означает /srv на источнике.

Метод «pull» сохраняет историю с помощью жестких ссылок. Неизмененные файлы в новом дереве являются жесткими ссылками на предыдущее дерево, поэтому они занимают место только под запись в каталоге, а не под вторую копию файла.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

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

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Будьте реалистичны в отношении стоимости этой схемы. Жесткие ссылки дедуплицируют только целые файлы, поэтому изменение одного байта внутри 4 GB образа диска приведет к копированию всех 4 GB, в то время как restic и PBS сохранили бы лишь несколько измененных блоков. Целевой хост также хранит ваши файлы в открытом виде, поэтому любой пользователь с правами root на резервном VPS может их прочитать.

Шифрование на стороне клиента: целевой сервер не видит открытый текст

Относитесь к VPS для резервных копий как к машине, которую вы не контролируете полностью. У неё есть провайдер, а у провайдера есть персонал и вышедшие из строя диски, которые покидают дата-центр.

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

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

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

У зеркал rsync нет аналогов. Файлы сохраняются в исходном виде. Если данные конфиденциальны, либо смиритесь с тем, что целевой сервер может их прочитать, либо используйте один из двух других способов.

Защита резервных копий от удаления скомпрометированным источником

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

В PBS эта проблема решается с помощью ролей. Токен с правами DatastoreBackup может записывать новые снимки и восстанавливать свои собственные, но не может выполнять очистку, так как для удаления снимка требуется отдельное право Datastore.Prune. Настройте политику хранения (retention) на стороне PBS, и тогда на исходном сервере никогда не будет учетных данных, способных что-либо удалить.

У restic при работе через SFTP такого разделения нет, так как SSH-ключ, записывающий данные в репозиторий, может их и удалять. Решение заключается в использовании REST backend. Запустите rest-server на сервере резервного копирования с флагом --append-only, который разрешает создание новых копий, но запрещает удаление и изменение существующих. Укажите клиенту адрес rest:https://backup.example.net:8000/web1, используя RESTIC_REST_USERNAME и RESTIC_REST_PASSWORD. В этом случае команда restic forget --prune с исходного сервера завершится ошибкой, что и требуется. Политика хранения в таком сценарии выполняется со второго сервера, имеющего собственные учетные данные. Руководство restic также рекомендует использовать --keep-within вместо политик, основанных на количестве копий, при работе с репозиториями в режиме «только добавление» (append-only). В противном случае злоумышленник может заполнить репозиторий «мусорными» снимками, вытеснив реальные данные за пределы окна --keep-last.

rsync решает ту же задачу структурно за счет использования модели «pull» (вытягивание), так как исходный сервер не обладает учетными данными для доступа к целевому.

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

Запланируйте тренировку по восстановлению данных

Резервная копия, которую вы ни разу не восстанавливали, — это лишь предположение. Выделяйте один час каждый квартал для проверки.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r отсутствие вывода означает, что восстановленное дерево файлов совпадает с исходным. В PBS для этого используется proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, а также запланированная задача проверки, которая повторно считывает фрагменты данных на целевом узле и сообщает о несовпадении контрольных сумм.

Тренировка должна доказывать не только целостность байтов.

• Выполняйте восстановление с третьей машины, а не с источника, так как вы исходите из того, что источник утрачен. Это означает, что пароль от репозитория или ключ PBS должны быть доступны без участия исходного сервера.
• Замерьте время восстановления, запишите результат и сравните его с заявленным RTO. Приведенная выше таблица показывает нижний предел скорости передачи данных. Реальное время также включает расшифровку, запись на диск и время, затраченное на выбор нужного снимка состояния (snapshot).
• Восстанавливайте данные, имеющие состояние, например, дамп базы данных, который затем нужно загрузить во временный экземпляр. Успешное извлечение tar-архива не гарантирует, что приложение запустится.

Самый дешевый диск в мире не имеет никакой ценности, пока вы хотя бы раз не восстановили с него данные.

FAQ

Является ли снапшот у провайдера VPS удаленной резервной копией?

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

Сколько дискового пространства нужно для хранения резервных копий за месяц?

Рассчитывайте объем исходя из возраста самой старой копии, а не из их количества. Инструмент с дедупликацией хранит каждый уникальный блок данных один раз, поэтому размер репозитория примерно равен размеру исходных данных плюс объем новых уникальных данных в день, умноженный на количество дней хранения. Для 500 GB данных, изменяющихся на 5 GB в день, недельный архив ежедневных копий составит около 535 GB, а годовая история — 2,325 GB. Заложите запас по объему, так как переполнение диска приведет к сбою следующего резервного копирования, а команде prune в restic требуется свободное место для переупаковки файлов перед тем, как оно будет освобождено.

Может ли скомпрометированный сервер удалить свои собственные удаленные резервные копии?

Да, если вы не предусмотрели защиту от этого. При использовании обычного репозитория SSH или SFTP ключ, который выполняет запись, может и удалять данные. Предоставьте источнику учетные данные, которые не позволяют удалять файлы: API-токен PBS с ролью DatastoreBackup, у которого отсутствует привилегия Datastore.Prune, или используйте restic с rest-server, запущенным с флагом --append-only, который запрещает удаление и изменение существующих копий. Модель «pull» (запрос данных сервером резервного копирования) еще надежнее, так как в этом случае на исходном сервере вообще нет учетных данных для доступа к серверу резервных копий. Управляйте политикой хранения со стороны сервера резервных копий, а не источника.

Что использовать на VPS для резервных копий: Proxmox Backup Server или restic?

Выбирайте инструмент в зависимости от того, что именно вы восстанавливаете. Если источник — Proxmox VE и вам нужно восстановить виртуальную машину целиком, используйте PBS: он работает на уровне образов дисков и восстанавливает VM за один шаг. Если источник — хост Linux и вам нужны файлы и дампы баз данных, используйте restic, которому требуется только SSH-доступ к целевой машине и который шифрует данные перед отправкой. Использование обоих инструментов — обычная практика: PBS для гипервизора, restic для серверов, которые на нем не работают.

Сколько времени занимает восстановление из резервной копии на VPS?

Разделите объем данных на скорость канала, чтобы получить минимальное время, затем добавьте время на расшифровку и запись. Передача 500 GB по каналу 100 Mbit/s займет 11.1 часов при работе на полной скорости, а то же восстановление через порт 1 Gbit/s — 1.1 часов. Восстановление множества мелких файлов происходит медленнее из-за накладных расходов на каждый файл. Проведите тестовое восстановление и используйте полученное значение, так как только на него можно полагаться в плане восстановления.