Як використати VPS для віддалених резервних копій

Якою насправді є віддалена ціль резервного копіювання

Віддалена ціль резервного копіювання — це інша машина, на якій зберігається копія ваших даних і яка виходить з ладу незалежно від оригіналу. Для більшості читачів найдешевший варіант — VPS в іншого провайдера. Реалістичні три варіанти: Proxmox Backup Server, що працює на VPS; репозиторій restic, доступний через SSH або S3; або дзеркальна копія rsync, яку отримує backup host. Вибір залежить від того, що саме потрібно відновлювати та наскільки швидко це потрібно зробити. Решту визначає те, хто має право видаляти копію.

Віддалене розташування означає інший домен відмови. Це означає іншого провайдера та обліковий запис, який не використовує спільні облікові дані для входу з обліковим записом, що керує вашим сервером. Другий сервер в іншому регіоні того самого провайдера переживе пожежу в одній будівлі. Але він не захистить від скомпрометованого входу до панелі керування, оскільки один обліковий запис керує обома копіями.

Snapshot у вашого провайдера не є другою копією. Він захищений тим самим паролем панелі керування, тому зловмисник, який отримав цей пароль, може за один сеанс видалити сервер і його snapshots. Сервіси snapshots також стягують плату за кожен гігабайт на місяць за тарифами, що значно перевищують вартість звичайного диска, тому зберігання таких копій протягом дев’яноста днів обходиться дорого. Варто прочитати Різниця між snapshots VPS і резервними копіями, перш ніж покладатися на будь-який із цих варіантів.

Яка з трьох схем вам підходить

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

Якщо не можете визначитися, використовуйте restic. Він шифрує дані до того, як вони залишають машину, а на цільовому сервері потрібні лише обліковий запис SSH і дисковий простір. У матеріалі Налаштування резервного копіювання restic на VPS докладніше описано налаштування клієнта, а матеріал restic і BorgBackup: порівняння допоможе зробити вибір, якщо ви вже використовуєте Borg.

Розрахунок цільового сховища: скільки коштує місяць зберігання

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

Тому розмір репозиторію залежить від віку найстарішого snapshot, а не від кількості snapshot. Візьмемо 500 GB даних і 5 GB нових унікальних даних щодня. Тоді репозиторій міститиме базові 500 GB плюс приблизно 5 GB за кожен день до найстарішого snapshot, який зберігає політика.

[
  {
    "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 US dollars за TB на місяць. Це лише приклад для арифметики, а не пропозиція конкретного провайдера, тому підставте фактичну ціну за TB для тарифного плану, який розглядаєте. Тиждень щоденних резервних копій займає приблизно 535 GB. Повний рік історії займає 2,325 GB, тобто $23.25 на місяць проти $5.35 за тиждень. Зберігати історію недорого. Ви платите переважно за базову копію.

Дедуплікація не допомагає для даних, які вже стиснуті або зашифровані. Стиснутий за допомогою gzip дамп бази даних повністю змінюється під час кожного запуску, тому кожен дамп записується як нові фрагменти, а репозиторій щоночі збільшується на повний розмір дампа. Створюйте дамп без стиснення і доручіть стискання інструменту резервного копіювання, оскільки restic підтримує стиснуті репозиторії починаючи з 0.14, а версія 0.19 додала режими zstd fastest і better. Фотографії та відео дедуплікуються так само погано з тієї самої причини, тому оцінюйте їхній обсяг за фактичним темпом зростання, а не за наведеними вище рядками.

У цьому випадку ви купуєте дисковий простір, який простоює, а не ресурси 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 місячного ліміту backup host. Перевірте цей ліміт і з’ясуйте, що зробить провайдер після його перевищення, перш ніж вам знадобляться дані.

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

Форма 1: Proxmox Backup Server як віддалене сховище даних

PBS підходить, якщо джерелом є Proxmox VE, а відновлюваною одиницею — віртуальна машина. VPS не може завантажити ISO Proxmox, тому встановіть PBS поверх Debian. Станом на August 2026 актуальною є Version 4.2, побудована на 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 окрему файлову систему або окремий том. Переповнений datastore зупиняє резервне копіювання, а 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, тому цей токен не може видалити snapshot, який він уже записав.

Політика зберігання в PBS має дві частини, і другу часто пропускають. Prune видаляє snapshot-и. Garbage collection видаляє chunks, на які не посилається жоден snapshot, що залишився. Вільне місце з’являється після 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, коли список snapshot-ів, які він планує видалити, стане правильним. Garbage collection виконується у дві фази: спочатку оновлюється час доступу кожного chunk, на який усе ще є посилання, а потім видаляються chunks, час доступу до яких старший за граничний момент. Цей момент настає за 24 години і 5 хвилин до початку виконання. Такий період очікування потрібен, щоб chunk, який записує поточне резервне копіювання, не було видалено під час операції. Заплануйте щоденний prune і щотижневу garbage collection для datastore. Також додайте verify job, щоб цільовий сервер повторно прочитав власні chunks і повідомив про пошкодження на диску до початку відновлення.

Якщо джерелом є сам екземпляр 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 підключається до домашнього datastore, тому домашній сервер не зберігає облікових даних, які можуть змінювати віддалену копію.

Форма 2: репозиторій restic через SSH або S3

Debian і Ubuntu містять restic у своїх репозиторіях пакетів, але відстають від upstream. Станом на August 2026 актуальна версія — 0.19.1. Встановіть офіційний бінарний файл на вихідному хості.

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.

На backup VPS створіть обліковий запис, якому не належить нічого іншого, а потім скопіюйте відкритий ключ вихідного хоста до /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

Збережіть цей пароль не на цьому сервері й не на backup target. Якщо ви його втратите, репозиторій стане непридатним для читання без жодної можливості відновлення. Саме так працює клієнтське шифрування.

Політика зберігання налаштовується однією командою. Її друга частина звільняє місце на диску.

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

forget видаляє snapshots. prune видаляє pack files, на які посилалися лише ці snapshots, а --prune автоматично запускає цю операцію, якщо щось справді було видалено. Без неї репозиторій ніколи не зменшується. restic check перевіряє структуру репозиторію, а --read-data-subset=10% повторно читає та обчислює хеші для однієї десятої pack files. Це виявляє пошкодження на target без витрат на читання всіх файлів. Інша форма, --read-data-subset=1/10, перевіряє одну фіксовану десяту частину. Тому щотижневе збільшення першого числа дає змогу перевірити весь репозиторій за десять тижнів.

Якщо виконання було примусово завершене, наступний запуск зупиниться з помилкою repository is already locked exclusively by PID. Переконайтеся, що резервне копіювання не виконується, а потім видаліть цей стан за допомогою restic unlock.

Для object storage рядок репозиторію стає таким: s3:https://s3.example.net/web1, а облікові дані зберігаються у AWS_ACCESS_KEY_ID та AWS_SECRET_ACCESS_KEY. Усе інше залишається без змін. Саме так restic підключається до self-hosted MinIO object store, запущеного на тому самому VPS.

Форма 3: rsync через SSH із ключем лише для отримання

Властивість безпеки цієї форми — напрямок з’єднання. Backup VPS підключається до джерела та зчитує дані. На джерелі немає ключа або маршруту до backup host, тому після компрометації джерела отримати доступ до резервних копій неможливо.

Створіть пару ключів на backup 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, тому перерване передавання ніколи не виглядає як готовий snapshot. Видаляйте старі дерева одним рядком, залишаючи тридцять.

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

Враховуйте вартість цієї форми. Жорсткі посилання усувають дублювання лише цілих файлів, тому зміна одного байта в образі диска розміром 4 GB копіює всі 4 GB. У restic і PBS у такому випадку зберігалося б лише кілька змінених фрагментів. Крім того, на цільовому сервері файли зберігаються у відкритому вигляді, тому будь-хто, хто має root на backup 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, може записувати нові snapshots і відновлювати власні snapshots, але не може виконувати prune, оскільки для видалення snapshot потрібен окремий привілей Datastore.Prune. Запускайте retention на стороні PBS, щоб на джерелі не зберігалися облікові дані, які дають змогу щось видаляти.

У restic через SFTP такого розділення немає, оскільки SSH key, який записує дані до repository, також може видаляти з нього дані. Рішенням є REST backend. Запустіть rest-server на backup VPS із параметром --append-only. Він дає змогу створювати нові backups, але забороняє видаляти та змінювати наявні. Після цього вкажіть клієнту адресу rest:https://backup.example.net:8000/web1 за допомогою RESTIC_REST_USERNAME і RESTIC_REST_PASSWORD. Команда restic forget --prune з джерела завершиться помилкою. Це очікуваний результат. Тому retention запускають з іншої машини з власними обліковими даними. У посібнику restic також рекомендовано --keep-within замість політик на основі кількості snapshots для append-only repositories. Інакше зловмисник може заповнити repository непотрібними snapshots і витіснити справжні snapshots за межі вікна --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/, а також запланованим завданням verify, яке повторно читає блоки на цільовому вузлі та повідомляє про помилки контрольних сум.

Тестове відновлення має підтвердити не лише цілісність даних.

• Виконуйте відновлення з третьої машини, а не з джерела, оскільки саме відсутність джерела ви припускаєте. Отже, пароль до репозиторію або ключ PBS має бути доступним без цієї машини.
• Виміряйте тривалість відновлення та запишіть результат, а потім порівняйте його із заявленим RTO. Наведена вище діаграма показує мінімальний час передавання. Фактичний час також охоплює розшифрування та запис на диск, а ще час, потрібний для визначення потрібного snapshot.
• Відновіть дані зі станом, наприклад дамп бази даних, який потім завантажте до тестового екземпляра. Факт успішного розпакування tar-файлу не доводить, що застосунок запуститься.

Навіть найдешевший диск у світі нічого не вартий, доки ви хоча б один раз не відновите з нього дані.

FAQ

Чи є snapshot у мого VPS-провайдера резервною копією в іншому місці?

Ні. Snapshot провайдера зберігається в тому самому обліковому записі, захищений тим самим входом до панелі керування та включений у той самий рахунок, що й сервер, з якого його створено. Той, хто отримає ці облікові дані, може за один сеанс видалити сервер і всі його snapshot. Snapshot корисні для швидкого відкату перед ризикованим оновленням, але вони не є копією в іншому місці. Копія в іншому місці зберігається в іншому обліковому записі, бажано в іншого провайдера, а вихідний сервер не повинен мати його облікових даних.

Скільки дискового простору потрібно для резервних копій, що зберігаються протягом місяця?

Розраховуйте обсяг за віком найстарішого snapshot, а не за кількістю snapshot. Інструмент із дедуплікацією зберігає кожен унікальний фрагмент один раз, тому репозиторій приблизно дорівнює розміру джерела плюс обсяг нових унікальних даних за день, помножений на кількість днів зберігання. Для 500 GB даних, які змінюються на 5 GB на день, тиждень щоденних копій становить приблизно 535 GB, а повна історія за рік — 2,325 GB. Додайте запас, оскільки переповнений диск не дасть створити наступну резервну копію, а restic's prune потребує вільного місця для перепакування pack files, перш ніж зможе його звільнити.

Чи може зламаний сервер видалити власні резервні копії в іншому місці?

Так, якщо не передбачити захист від цього. У звичайному SSH або SFTP-репозиторії ключ, який має право запису, також може видаляти дані. Надайте джерелу облікові дані, які не дають змоги видаляти дані: PBS API token лише з роллю DatastoreBackup, якій бракує привілею Datastore.Prune, або використовуйте restic із rest-server, запущеним із параметром --append-only. Такий режим забороняє видалення та зміну наявних резервних копій. Pull-схема забезпечує ще кращий захист, оскільки джерело взагалі не має облікових даних хоста резервного копіювання. Запускайте політику зберігання з боку, який не є джерелом.

Чи слід запускати Proxmox Backup Server або restic на backup VPS?

Вибирайте інструмент відповідно до об’єкта відновлення. Якщо джерелом є Proxmox VE і потрібно відновити всю віртуальну машину, використовуйте PBS, оскільки він створює резервні копії на рівні образів дисків і відновлює VM за один крок. Якщо джерелом є Linux-хост і потрібно відновити файли та дампи баз даних, використовуйте restic. Для нього потрібен лише SSH-акаунт на цільовому хості, а шифрування виконується до передавання даних. Використовувати обидва інструменти нормально: PBS — для гіпервізора, а restic — для серверів, які на ньому не розміщені.

Скільки часу триває відновлення з резервної копії VPS?

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