---
title: "Резервное копирование VPS: rsync, restic и правило 3-2-1"
description: "Как делать бэкапы VPS: правило 3-2-1, что копировать, rsync на другой сервер, restic с шифрованием и историей, расписание systemd timer и проверка восстановления."
url: https://tihost.io/blog/vps-backup
language: ru
section: "Руководства"
published: 2026-10-05
updated: 2026-10-05
publisher: Tihost (https://tihost.io)
---

# Резервное копирование VPS: rsync, restic и правило 3-2-1

> **Коротко:** Резервные копии VPS делают по правилу 3-2-1: три копии данных, на двух разных носителях, одна - вне сервера и площадки. Копируют данные, конфиги из /etc и дампы баз, а не всю систему: ОС переустанавливается за минуты. Удобнее всего restic - он шифрует и дедуплицирует копии, хранит историю по политике вроде 7 дневных, 4 недельных и 6 месячных снимков и запускается по systemd timer каждую ночь.

**Главное:**

- Правило 3-2-1 для резервных копий: три копии данных, на двух разных носителях, одна из них - вне основной площадки; копия на том же VPS от потери сервера не спасает.
- Для бэкапа VPS копируют данные приложений, конфиги из `/etc`, домашние каталоги и дампы баз данных, а не всю систему: ОС на VPS переустанавливается за несколько минут.
- Файлы работающей базы данных копировать нельзя - они получаются несогласованными; сначала делают дамп (`pg_dump -Fc` для PostgreSQL), а копируют уже его.
- restic шифрует и дедуплицирует резервные копии, хранит историю снимков и чистит старые командой `restic forget --prune` по политике, например 7 дневных, 4 недельных и 6 месячных.
- Резервная копия считается рабочей только после проверки восстановления: раз в месяц восстановите `restic restore` несколько файлов и дамп базы в отдельную базу.

> Команды рассчитаны на Ubuntu 22.04/24.04 и Debian 12 и выполняются на сервере, который копируют. Второй сервер для копий - любой Linux с SSH и пользователем `backup`; примеры адресов - `203.0.113.20`.

## Зачем свои резервные копии, если сервер надёжный

Надёжность железа и SLA защищают от поломки диска, но не от ошибок и атак: `rm -rf` не в том каталоге, неудачное обновление, взлом, шифровальщик, удалённая по ошибке таблица или неоплаченный сервер. Во всех этих случаях копия на том же VPS пропадает вместе с данными. Поэтому собственные копии вне сервера нужны всегда - независимо от того, где он работает и что обещает провайдер.

## Что такое правило 3-2-1

Правило 3-2-1 - классическая схема резервного копирования: 3 копии данных (рабочая и две резервные), на 2 разных носителях или системах, 1 копия - в другом месте. Для VPS это выглядит так:

| Копия | Где хранится | От чего защищает |
| --- | --- | --- |
| Рабочие данные | Сам VPS | Ни от чего - это оригинал |
| Резервная копия 1 | Второй сервер в другой локации | Потеря, взлом или удаление основного VPS |
| Резервная копия 2 | Объектное хранилище S3 или домашний компьютер | Одновременная проблема с обоими серверами |

## Шаг 1. Решите, что копировать

- `/etc` - конфиги nginx, systemd, SSH, файрвола: на их повторную настройку уходят часы;
- данные приложений - `/home`, `/opt`, `/srv`, `/var/www` или где лежат ваши проекты, включая файлы `.env`;
- дампы баз данных - PostgreSQL, MySQL, SQLite, а не файлы работающей базы;
- тома Docker (`/var/lib/docker/volumes`), если данные живут в контейнерах, - лучше тоже через дамп базы;
- не нужно копировать систему целиком: `/usr`, `/var/cache`, `/proc`, `/tmp` и `node_modules` восстанавливаются установкой ОС и пакетов.

## Шаг 2. Делайте дампы баз перед копированием

Файлы базы данных, скопированные на ходу, почти наверняка окажутся несогласованными, и база из них не поднимется. Дамп снимается с работающей базы без остановки и всегда согласован. Пример для PostgreSQL - подробнее в статье [про PostgreSQL на VPS](https://tihost.io/blog/postgresql-on-vps):

```bash
sudo mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc myapp | sudo tee /var/backups/db/myapp.dump > /dev/null
sudo ls -lh /var/backups/db
```

## Шаг 3. Настройте вход на сервер копий по SSH-ключу

Копирование по расписанию работает без пароля, поэтому для него нужен отдельный SSH-ключ root. `ssh-copy-id` один раз попросит пароль пользователя `backup` на втором сервере, а запись в `/root/.ssh/config` даёт ему короткое имя `backup-server`. О ключах подробнее - в статье [про подключение по SSH](https://tihost.io/blog/ssh-connect-to-vps):

```bash
sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/backup_key
sudo ssh-copy-id -i /root/.ssh/backup_key.pub backup@203.0.113.20
sudo tee -a /root/.ssh/config > /dev/null <<'EOF'
Host backup-server
    HostName 203.0.113.20
    User backup
    IdentityFile /root/.ssh/backup_key
EOF
```

## Шаг 4. Простой вариант: rsync на другой сервер

rsync копирует только изменившиеся файлы, поэтому повторный запуск занимает секунды. `-a` сохраняет права и даты, `--delete` удаляет на копии файлы, которых больше нет на сервере. rsync должен быть установлен на обоих серверах:

```bash
sudo apt install -y rsync
sudo rsync -a --delete /etc /home /opt /var/backups backup-server:/srv/backup/myvps/
```

> rsync с `--delete` делает зеркало, а не историю: если файл испорчен или удалён, при следующем запуске испорченная версия попадёт и в копию. Для защиты от ошибок и шифровальщиков нужны снимки за несколько дней - их делает restic.

## Шаг 5. restic: шифрование, дедупликация и история

restic хранит копии снимками (snapshot): каждый снимок - полное состояние на момент запуска, но одинаковые части файлов хранятся один раз (дедупликация), поэтому 30 ежедневных снимков редко меняющихся данных занимают немногим больше одного. Всё шифруется на вашем сервере, и сервер копий видит только зашифрованные блоки. Репозиторий по SFTP использует ключ из шага 3:

```bash
sudo apt install -y restic
sudo sh -c 'openssl rand -base64 32 > /root/.restic-password && chmod 600 /root/.restic-password'
sudo -i
export RESTIC_REPOSITORY=sftp:backup-server:/srv/restic/myvps
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
```

> Сохраните пароль из `/root/.restic-password` ещё и в менеджере паролей. Без него восстановить копию невозможно - даже если сам репозиторий цел.

Первый снимок, список снимков, чистка по политике хранения и проверка целостности репозитория. `forget --prune` оставляет 7 последних дневных, 4 недельных и 6 месячных снимков и удаляет данные, на которые больше не ссылается ни один снимок:

```bash
restic backup /etc /home /opt /var/backups --exclude-caches
restic snapshots
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
```

Кроме SFTP restic умеет писать в S3-совместимые хранилища - так удобно сделать вторую резервную копию по правилу 3-2-1. Список поддерживаемых хранилищ - в документации на [restic.net](https://restic.net/).

## Шаг 6. Запускайте копирование по расписанию

Соберите дамп и restic в один скрипт: `set -eu` остановит его на первой ошибке, и битый дамп не уйдёт в копию как удачный:

```bash
sudo tee /usr/local/sbin/backup.sh > /dev/null <<'EOF'
#!/bin/sh
set -eu
export RESTIC_REPOSITORY=sftp:backup-server:/srv/restic/myvps
export RESTIC_PASSWORD_FILE=/root/.restic-password

# дамп базы - если на сервере есть PostgreSQL
mkdir -p /var/backups/db
runuser -u postgres -- pg_dump -Fc myapp > /var/backups/db/myapp.dump

restic backup /etc /home /opt /var/backups --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF
sudo chmod 700 /usr/local/sbin/backup.sh
```

systemd timer запускает скрипт каждую ночь в 03:30 со случайной задержкой до 15 минут, а `Persistent=true` выполнит пропущенный запуск, если сервер в это время был выключен. Результат каждого запуска виден в `journalctl -u backup`:

```bash
sudo tee /etc/systemd/system/backup.service > /dev/null <<'EOF'
[Unit]
Description=Restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh
EOF
sudo tee /etc/systemd/system/backup.timer > /dev/null <<'EOF'
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer
```

Если привычнее cron, та же задача - одна строка в `sudo crontab -e`:

`crontab`:

```
30 3 * * * /usr/local/sbin/backup.sh >> /var/log/backup.log 2>&1
```

## Шаг 7. Проверьте восстановление

Резервная копия, из которой ни разу не восстанавливали, - это надежда, а не бэкап. Раз в месяц восстановите несколько файлов во временный каталог и сравните с оригиналом, а дамп базы разверните в отдельную базу через `pg_restore`:

```bash
restic snapshots
restic restore latest --target /root/restore-test --include /etc/nginx
diff -r /etc/nginx /root/restore-test/etc/nginx && echo OK
```

Заодно засеките время: сколько займёт поднять всё на чистом сервере - установить ОС, пакеты, вернуть `/etc`, данные и базу. Этот план восстановления стоит записать до аварии, а не во время неё.

## Куда складывать копии

| Хранилище | Плюсы | Минусы |
| --- | --- | --- |
| Второй VPS в другой стране | Полный контроль, работают rsync и restic по SFTP | Нужно обслуживать второй сервер |
| Объектное хранилище S3 | Не нужно администрировать, оплата за объём | Плата за хранение и скачивание |
| Домашний компьютер или NAS | Бесплатно, копия физически у вас | Зависит от домашнего интернета и питания |

У Tihost три локации - Германия, Финляндия и Польша, поэтому сервер для копий удобно взять в другой стране, чем основной: авария одного дата-центра не затронет обе копии. Как выбрать локацию - в статье [о выборе локации VPS](https://tihost.io/blog/vps-location-choice). Для хранилища копий подходят конфигурации Starter - в старшей из них диск больше всего:

| Конфигурация | Германия | Финляндия | Польша |
| --- | --- | --- | --- |
| 1 vCPU / 2 GB RAM / 40 GB NVMe | $4.00 | $4.00 | $5.00 |
| 2 vCPU / 4 GB RAM / 80 GB NVMe | $7.70 | $7.70 | $9.60 |
| 4 vCPU / 4 GB RAM / 140 GB NVMe | $12.30 | $12.30 | $15.40 |

**Запустите сервер за 2 минуты.** AMD Ryzen 9, NVMe и защита от DDoS в Германии, Финляндии и Польше. Оплата криптовалютой или картой. [Заказать сервер](https://tihost.io/login)

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

### Что такое правило резервного копирования 3-2-1?

Правило 3-2-1 - это три копии данных, на двух разных носителях или системах, и одна из них - вне основной площадки. Для VPS это сам сервер, копия на втором сервере в другой локации и ещё одна в объектном хранилище или дома.

### Чем restic лучше rsync для резервных копий?

rsync с `--delete` поддерживает зеркало, и испорченный или удалённый файл при следующем запуске пропадает и из копии. restic хранит историю снимков, шифрует данные и дедуплицирует их, поэтому можно вернуться к состоянию недельной давности.

### Нужно ли копировать весь VPS целиком?

Нет. Достаточно копировать `/etc`, данные приложений, домашние каталоги и дампы баз данных. ОС и пакеты быстрее переустановить, а копия всей системы занимает больше места и хуже переносится на другой сервер.

### Можно ли просто скопировать каталог базы данных?

Копировать файлы работающей базы данных нельзя: копия получится несогласованной. Сначала сделайте дамп - `pg_dump -Fc` для PostgreSQL или `mysqldump` для MySQL - и копируйте файл дампа.

### Как часто делать резервные копии VPS?

Для большинства проектов достаточно ежедневной копии ночью с хранением 7 дневных, 4 недельных и 6 месячных снимков. Если потеря данных за сутки недопустима, базу копируют чаще - например, каждый час.

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

Без пароля репозиторий restic расшифровать невозможно, и все копии в нём бесполезны. Храните пароль не только на сервере, но и в менеджере паролей.

---

Обновлено 2026-10-05 · https://tihost.io/blog/vps-backup