Как шифровать бэкапы

Краткий ответ: Шифруйте бэкапы до или во время выхода из источника: 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 →