Резервные копии VPS: архив файлов, дамп базы и копия на свой компьютер

Минимальный бэкап руками: tar для /etc, /var/www и /home, mysqldump или pg_dumpall для базы, scp на компьютер. И почему копия на самом сервере — не копия.

4 ноября 2026 г.·2 мин чтения·backup, tar, mysql, postgresql

Резервная копия — страховка от взлома, случайного rm -rf, неудачного обновления и ошибок в собственных скриптах. Сделать её руками занимает пять минут. Ниже минимальный вариант без дополнительных программ; автоматический ежедневный бэкап в S3 — в статье restic.

Копия на самом сервере — не копия. Если сервер взломают или диск умрёт, она пропадёт вместе со всем остальным. Сразу забирайте архив на свой компьютер или в облако.

1. Архив важных папок

Обычно всё ценное лежит в трёх местах: /etc (настройки системы и сервисов), /var/www (сайты) и /home (данные пользователей). Если приложения живут в /opt — добавьте и его.

sudo tar -czf /tmp/backup-$(date +%F).tar.gz /etc /var/www /home
sudo chown $USER: /tmp/backup-*.tar.gz
ls -lh /tmp/backup-*.tar.gz

Если какой-то папки нет, tar предупредит и упакует остальное — это нормально.

2. Дамп базы данных

Файлы работающей базы копировать нельзя: получится несогласованный мусор. Нужен дамп.

MySQL и MariaDB:

sudo mysqldump --all-databases --single-transaction -u root -p > /tmp/databases-$(date +%F).sql
sudo chown $USER: /tmp/databases-*.sql

PostgreSQL:

sudo -u postgres pg_dumpall > /tmp/databases-$(date +%F).sql

База в Docker — дамп делается через exec в контейнер:

docker compose exec -T db pg_dump -U app app > /tmp/app-$(date +%F).sql
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --all-databases > /tmp/app-$(date +%F).sql

Если базы нет — пропустите шаг.

3. Скачайте копию к себе

На своём компьютере:

scp admin@IP_СЕРВЕРА:/tmp/backup-2026-11-04.tar.gz .
scp admin@IP_СЕРВЕРА:/tmp/databases-2026-11-04.sql .

Если SSH на другом порту: scp -P 2222 .... На Windows scp есть в PowerShell, а для перетаскивания мышкой подойдёт FileZilla с адресом sftp://IP_СЕРВЕРА.

Затем удалите временные файлы на сервере — в них пароли из /etc и содержимое базы:

rm /tmp/backup-*.tar.gz /tmp/databases-*.sql

Проверяйте копии

Бэкап, из которого никто ни разу не восстанавливался, считается несуществующим. Хотя бы посмотрите, что внутри:

tar -tzf backup-2026-11-04.tar.gz | head -50

Раз в несколько месяцев разверните копию на тестовом сервере целиком: сервер на tanaka.host можно создать на час и удалить, это стоит копейки.

Когда делать

Перед любым серьёзным изменением: обновление панели, миграция базы, смена версии PHP.
Минимум раз в неделю для рабочих проектов, а лучше каждую ночь автоматически.

Автоматизация с шифрованием, дедупликацией и ротацией — в статье Бэкап VPS в S3 с помощью restic.