Як зробити резервні копії незмінними проти програм-вимагачів на моєму власному сервері?

Що означає незмінність для резервної копії?

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

Незмінна резервна копія закриває ці двері. Машина, з якої роблять резервну копію, може додавати нові дані, але ніщо з того, що вона містить, не може видалити чи перезаписати старі версії. Деякі методи забезпечують це правами доступу, інші — блокуванням із датою завершення.

Якщо машина, яку ви захищаєте, може видалити власні резервні копії, то й кожен, хто захопить цю машину, зможе це зробити.

Як restic і Borg працюють у режимі лише для дописування?

rest-server від restic має прапорець --append-only. У його README сказано, що режим дозволяє нові резервні копії, але забороняє видалення та зміну наявних. Виконуйте prune з адмінської машини через другий екземпляр без прапорця або на самому сервері.

Borg забезпечує цей режим примусовою командою в authorized_keys або append_only = 1 у конфігурації репозиторію. Його документація прямо перелічує обмеження:

• borg delete і borg prune усе ще виконуються; вони лише позначають дані як видалені.
• Наступний запис у звичайному режимі видаляє ці дані остаточно, тож автоматичний prune робить режим безглуздим.
• Виконайте borg check перед prune репозиторію, що працює лише для дописування.
• rm усе ще працює з файлами, тож клієнти мають звертатися до репозиторію лише через borg serve.

Обидва інструменти порівнюються на сторінці restic чи Borg для офсайт-резервних копій.

# restic: rest-server, one private repository per user
rest-server --path /tank/restic --append-only --private-repos --tls \
  --tls-cert /etc/rest-server/cert.pem --tls-key /etc/rest-server/key.pem

# Borg: in ~backup/.ssh/authorized_keys, one line per client key
command="borg serve --append-only --restrict-to-path /tank/borg/web1",restrict ssh-ed25519 AAAA... web1

Як Proxmox Backup Server і Veeam блокують резервні копії?

Proxmox Backup Server працює через ролі. Користувач із DatastoreBackup може створювати резервні копії та відновлювати власні, але для prune потрібен DatastorePowerUser. Збирання сміття також чекає 24 години й 5 хвилин, перш ніж видалити фрагменти. Поєднайте це із завданням синхронізації, яке витягує офсайт-сервер, щоб удома не було офсайт-логіну. Повне налаштування описано на сторінці офсайт-сервер Proxmox Backup Server на орендованому сервері.

Захищений репозиторій Veeam працює через час. Файли залишаються незмінними від 7 до 9999 днів, а облікові дані, якими встановлювали служби Veeam, ніколи не зберігалися. Кроки для орендованої машини описано на сторінці захищений репозиторій Veeam на орендованому Linux-сервері.

Чи можу я використовувати S3 Object Lock на власному сервері?

Лише якщо ваш S3-сервер його реалізує, і два найвідоміші open-source варіанти різняться.

• MinIO документує блокування об'єктів у версійованих бакетах у режимі GOVERNANCE або COMPLIANCE. У режимі COMPLIANCE жоден користувач не може змінити заблоковану версію, включно з root-користувачем. Але репозиторій спільноти MinIO архівовано 25 квітня 2026 року, він більше не підтримується і постачається лише як вихідний код.
• Garage на своїй сторінці сумісності з S3 зазначає Object Lock і версіювання бакетів як відсутні.

На стороні клієнта Kopia підтримує Object Lock: його потрібно ввімкнути в бакеті під час створення, і Kopia радить режим compliance. Інша порада працює будь-де: ключ доступу без прав на видалення. Інші S3-сервери порівнюються на сторінці найкращі альтернативи MinIO для власного S3.

Як знімки ZFS захищають резервну копію від власного клієнта?

Нехай клієнт пише через SFTP або rsync як звичайний обліковий запис, а знімки робить root. OpenZFS описує знімок як копію файлової системи лише для читання. Обліковий запис клієнта не отримує права destroy через zfs allow, тож не може видалити знімки.

Утримання додає друге блокування. Поки знімок має утримання, zfs destroy на ньому завершується з EBUSY, доки хтось не звільнить утримання.

Знімки, які робить root на наборі даних, куди пише клієнт, перетворюють будь-яку ціль rsync чи SFTP на версійовану, лише для дописування.

snap=tank/backup@$(date +%F)
zfs snapshot "$snap"
zfs hold keep "$snap"
zfs holds "$snap"        # lists the hold named keep

Що ще видаляє незмінні резервні копії на орендованому сервері?

Дві речі, і обидві поза межами програмного забезпечення для резервного копіювання.

• Root на сервері резервних копій. Кожен метод вище зрештою поступається root. Тримайте root на ключі, якого ніколи немає на машинах, з яких ви робите резервні копії, і обмежте SSH своєю адміністративною адресою.
• Сама оренда. Кожен сервер оплачується наперед з вашого крипто-балансу на 30 днів, 3 місяці, 6 місяців або 12 місяців — за вашим вибором під час оформлення замовлення. Автопродовження знову списує кошти за той самий термін за ціною, з якою ви починали, якщо ви не встановили інший термін для наступного продовження в дашборді; коли балансу не вистачає, сервер зупиняється в кінці свого терміну, його диски зберігаються 7 днів, а потім стираються. Перезавантаження, перевстановлення та скасування запитуються в дашборді й обробляються командою; перевстановлення стирає всі диски, включно з дисками для даних. Блокування, довше за оплачений термін, нічого не захищає.

Сервер зберігання не є резервною копією самого себе: ми не зберігаємо копію ваших даних деінде, тому друга копія в іншому місці залишається вашим завданням. Заблоковані версії також не можна достроково видалити, тож пул зростає з кожною збереженою версією. Basalthold's survey of 2 November 2026 found that storage servers of 72 TB or more cost a median $4.86 per TB a month at hosts taking crypto without KYC. Hold 100 коштує $3.77/TB без обробки. Терміни до 12 місяців є в прайс-листі утримання.