MAATRIX / Блог / Зашифрованные бэкапы на VPS: restic и borg на практике

Зашифрованные бэкапы на VPS: restic и borg на практике

Бэкапы с шифрованием на VPS: restic и borg
Блог MAATRIX · 2026-07-07

Бэкап без шифрования — это утечка, ждущая своего часа: снапшот на чужом хранилище читает любой, кто до него добрался. restic и borg решают всё сразу — шифрование AES, дедупликация и инкрементальность. Разберём оба инструмента, автоматизацию и проверку восстановления.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Почему restic и borg, а не tar + gpg

Классический tar + gpg работает, но каждый бэкап — полная копия, а шифрование накладывается сверху и ломает дедупликацию. restic и borg делают это правильно:

  • Шифрование по умолчанию — данные шифруются до записи в репозиторий
  • Дедупликация — одинаковые блоки хранятся один раз, экономия в разы
  • Инкрементальность — каждый снапшот хранит только изменения
  • Проверка целостности — встроенный check по хешам

restic проще и умеет из коробки писать в S3, B2, SFTP. borg чуть быстрее на локальных и SSH-хранилищах и экономнее по месту.

Дедупликация работает на уровне блоков переменной длины: если вы забэкапили 10 ГБ, а завтра изменился один файл на 1 МБ, второй снапшот займёт не 10 ГБ, а мегабайты. За счёт этого можно хранить сотни ежедневных срезов, укладываясь в объём чуть больше одной полной копии. При этом каждый снапшот выглядит как полный — восстановить можно любой из них независимо, без цепочки инкрементов, как в старых схемах, где потеря одного звена ломала всё.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS с ежедневными бэкапами

restic: настройка за 5 минут

Ставим и инициализируем репозиторий. Пароль — ключ шифрования, без него данные не прочитать:

apt update && apt install -y restic
export RESTIC_REPOSITORY="/mnt/backup/repo"
export RESTIC_PASSWORD="длинный-случайный-пароль"
restic init

Первый бэкап и последующие — одна команда, restic сам делает инкремент:

restic backup /etc /var/www /home --exclude-caches
restic snapshots

Ротация — удаляем старьё, оставляя разумную глубину:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Бэкап на удалённое хранилище через SFTP

Держать бэкап на том же сервере — плохая идея: упадёт диск, потеряете всё. Пишем на второй VPS или в объектное хранилище. Пример через SFTP:

export RESTIC_REPOSITORY="sftp:backup@backup-host:/srv/restic"
restic backup /var/www

Для S3-совместимых хранилищ:

export RESTIC_REPOSITORY="s3:https://s3.endpoint.com/my-bucket"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
restic backup /var/www

Автоматизация и borg-альтернатива

Заворачиваем в systemd timer или cron. Скрипт /usr/local/bin/backup.sh с секретами вне истории команд:

#!/bin/bash
set -euo pipefail
export RESTIC_REPOSITORY="sftp:backup@backup-host:/srv/restic"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
restic backup /etc /var/www /home --exclude-caches --tag auto
restic forget --keep-daily 7 --keep-weekly 4 --prune
restic check --read-data-subset=5%
chmod 700 /usr/local/bin/backup.sh
chmod 600 /root/.restic-pass
# cron: каждый день в 3:30
30 3 * * * /usr/local/bin/backup.sh >> /var/log/restic.log 2>&1

borg по духу похож: borg init --encryption=repokey-blake2 /path/repo, затем borg create ::{hostname}-{now} /var/www. repokey хранит ключ в репозитории (защищён паролем), keyfile — отдельно.

Секрет храните в файле через RESTIC_PASSWORD_FILE, а не в переменной RESTIC_PASSWORD напрямую: переменные окружения видны в /proc/PID/environ и могут утечь в логи. Флаг --exclude-caches пропускает каталоги, помеченные тегом CACHEDIR.TAG — это отсекает мусор вроде node_modules и кэшей сборки. Команда restic check --read-data-subset=5% в конце скрипта выборочно перечитывает данные и проверяет, что репозиторий не бьётся — дешёвая страховка от тихого повреждения на хранилище.

Проверка восстановления — обязательна

Бэкап, который не пробовали восстановить, не существует. Регулярно проверяйте:

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

Схема надёжна: рабочий сервер шлёт зашифрованные снапшоты на второй VPS. У MAATRIX сервера на AMD EPYC + NVMe от $8/мес, а на всех тарифах есть ещё и ежедневные бэкапы на стороне провайдера — второй пояс безопасности. Локации UK, США и РФ, root-доступ, оплата картой РФ, СБП, криптой или токеном MAAT. Второй дешёвый VPS под restic-репозиторий — самый спокойный сон админа.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS с ежедневными бэкапами

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Частые вопросы

Что будет, если потерять пароль restic?

Данные восстановить невозможно — это стойкое шифрование. Храните пароль в менеджере секретов и держите резервную копию отдельно от репозитория.

restic или borg — что выбрать?

restic — если нужны облачные бэкенды (S3/B2) и простота. borg — если храните на SSH/локально и важна максимальная экономия места и скорость.

Достаточно ли бэкапов провайдера?

Провайдерские бэкапы — это защита от аппаратных сбоев. Свои зашифрованные снапшоты на отдельном хосте защищают ещё и от компрометации самого сервера и ошибок.