Як шифрувати бекапи

Коротка відповідь: Шифруйте бекапи до або під час виходу з джерела: restic і borg шифрують за замовчуванням парольною фразою на ваш вибір, а gpg може загорнути звичайні tar/SQL-архіви. Зберігайте парольну фразу там, де вона переживе втрату сервера — зашифровані бекапи із загубленим ключем це просто шум.

Огляд

Шифрування захищає копії, які зазвичай подорожують далі й живуть довше за оригінали. З клієнтським шифруванням сховищний сервер бачить лише шифротекст — навіть хтось із повним доступом до Storage VPS не прочитає нічого. Ціна: керування ключами стає частиною вашого плану аварійного відновлення.

Що потрібно мати

• Конвеєр бекапів, який захищаємо (гайд налаштування).
• Рішення щодо інструментів: restic/borg (шифрування вбудоване) чи gpg поверх tar/rsync.
• Безпечне місце для ключів і парольних фраз поза серверами: менеджер паролів плюс офлайн-копія.

Покрокова інструкція

1. restic — зашифрований, дедуплікований, інкрементальний:

   restic -r sftp:[email protected]:/srv/backups/web1 init
   restic -r sftp:[email protected]:/srv/backups/web1 backup /var/www /etc

   Парольна фраза, задана при init, шифрує все; без неї репозиторій нечитабельний.
2. borg — та сама ідея:

   borg init --encryption=repokey-blake2 [email protected]:/srv/backups/web1/repo
   borg create ssh://[email protected]/srv/backups/web1/repo::{now} /var/www /etc

   З repokey експортуйте також ключ: borg key export — зберігайте експорт разом із парольною фразою.
3. gpg для класичних архівів:

   tar czf - /var/www | gpg --symmetric --cipher-algo AES256 -o web-$(date +%F).tar.gz.gpg

   Розшифрування: gpg -d web-2026-07-15.tar.gz.gpg | tar xzf -.
4. Задепонуйте секрети: парольна фраза + (для borg) експортований ключ у менеджер паролів і одне офлайн-місце; додайте "дістати ключі бекапів" нульовим кроком вашого DR-плану.
5. Тестуйте розшифрування-відновлення щокварталу — шифрування додає ще одну річ, яка мусить спрацювати під стресом (див. перевірку цілісності).

Типові проблеми

• Парольна фраза поруч із бекапами: PASSWORD.txt у каталозі репозиторію зводить нанівець усю вправу.
• Ключ існував лише на мертвому сервері: найпоширеніша історія повної втрати — депонуйте до першого нічного запуску.
• Шифрування єдиної копії на місці: шифрування — для резервних копій; не замінюйте живі дані зашифрованим блобом і не називайте це готовим.

Коли звертатися в підтримку

Cloud2Y не може відновити втрачену парольну фразу шифрування — ніхто не може, у цьому й сенс. З усім інфраструктурним (збої передач, помилки диска на репозиторії) — відкрийте тикет.

Часті запитання

Чи шифрують restic і borg бекапи за замовчуванням?

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

Що буде, якщо я втрачу парольну фразу бекапів?

Дані невідновні — так задумано, ніхто, включно з Cloud2Y, не розшифрує їх. Спершу задепонуйте парольну фразу (і borg key export) у менеджері паролів плюс одній офлайн-копії.

Як шифрувати звичайні tar чи SQL-бекапи?

Пропустіть їх через gpg, напр. "tar czf - /var/www | gpg --symmetric --cipher-algo AES256 -o site.tar.gz.gpg" — одна команда додає стійке шифрування будь-якому класичному архівному процесу.

Схожі статті

• Як захистити доступ до бекапів
• Як перевірити цілісність бекапів
• Як створити план аварійного відновлення
• Політика зберігання бекапів: пояснення

Готові почати? Замовити Storage VPS у Cloud2Y →