Как контролировать VPS и вручную скачать резервную копию

Наблюдение и резервная копия решают разные задачи. Проверка доступности отвечает, работает ли сайт сейчас. Резервная копия нужна, когда файлы, настройки или весь VPS уже потеряны. Работающий мониторинг не восстановит данные, а свежий архив сам не сообщит о недоступном сайте.

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

Определите, что именно нельзя потерять

Не нужно архивировать весь системный диск без разбора. Часть VPS можно воспроизвести: Ubuntu устанавливается из образа, пакеты — из репозиториев, а статический сайт — из Git. В копию в первую очередь входят уникальные данные и сведения, без которых восстановление станет догадкой.

Для простого статического сайта сохраните:

• активную конфигурацию домена в Nginx;
• локальные unit-файлы systemd, если есть серверное приложение;
• скрипты публикации, которые отсутствуют в Git;
• пользовательские загрузки и другие изменяемые файлы;
• дамп базы данных, если сайт её использует;
• список доменов, путей, служб и команд восстановления.

Сертификаты и закрытые ключи требуют отдельной защиты. Сертификат Let’s Encrypt можно выпустить заново при сохранённом контроле домена. Другие ключи копируйте только в зашифрованное локальное хранилище и не смешивайте с обычным архивом, доступным всем пользователям компьютера.

Каталоги node_modules, кеши сборщика и старые статические выпуски обычно можно пересоздать. Но это верно только при доступном репозитории, сохранённом lock-файле и проверенной команде сборки.

Запишите допустимый возраст копии

Частоту ручной выгрузки определяет скорость изменения данных. Если статический сайт обновляется раз в месяц и каждая версия есть в Git, копию конфигурации можно делать после её изменения. Если посетители ежедневно загружают файлы, ручной архив раз в месяц оставляет риск потерять почти месяц данных.

Запишите два понятных ограничения:

• сколько последних изменений допустимо потерять;
• сколько времени можно потратить на восстановление.

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

Проверяйте сайт глазами внешнего посетителя

Самая простая независимая проверка выполняется на домашнем компьютере или телефоне через другую сеть. Она проходит через DNS, фильтры провайдера, HTTPS и Nginx, поэтому видит больше, чем запрос с самого VPS.

Команда ниже получает страницу, считает ответы 400 и 500 ошибкой, ограничивает время и не печатает HTML:

curl --fail --silent --show-error --max-time 10 https://example.org/ > /dev/null

Замените домен своим. Отсутствие вывода и код завершения 0 означают успешный HTTP-ответ. При ошибке curl покажет причину: невозможность получить DNS-адрес, тайм-аут, ошибку сертификата или HTTP-код.

Для постоянного уведомления нужен внешний сервис или другая всегда включённая машина. Но даже без него ручная проверка должна включать главную страницу, одну важную внутреннюю страницу и несуществующий адрес с настоящим кодом 404.

Быстро оцените состояние самого VPS

Если внешний запрос не прошёл, подключитесь по SSH и посмотрите четыре базовых показателя. Команды ниже ничего не исправляют, а помогают определить направление дальнейшей проверки:

uptime
free -h
df -h /
systemctl --failed

uptime показывает, как долго работает сервер и какова средняя нагрузка. free -h — общую и доступную оперативную память. df -h / — занятое и свободное место в корневой файловой системе. systemctl --failed перечисляет службы, которые systemd не смог запустить.

Само по себе большое число не всегда означает аварию. Важнее изменение относительно обычного состояния: место постоянно уменьшается, служба впервые стала failed, а время ответа одновременно выросло. Для конкретной службы используйте systemctl и journalctl по небольшому интервалу.

Не перезагружайте VPS только ради исчезновения симптома до сохранения времени, статуса и журнала. Перезагрузка может временно освободить память, но скрыть процесс, который её расходовал.

Подготовьте локальный каталог для копий

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

backups/
└── vps-example-2026-09-05.tar.gz

Если компьютер использует облачную синхронизацию, заранее решите, допустимо ли помещать туда серверные конфигурации. Архив с закрытыми данными нужно шифровать до синхронизации. Локальный диск также может сломаться, поэтому важные копии стоит периодически переносить ещё на один принадлежащий владельцу носитель.

Создайте архив на VPS только из выбранных путей

Перед командой проверьте каждый путь отдельно через ls -ld. В примере копируются конфигурации Nginx, локальные службы systemd и данные конкретного сайта. Измените список под свой сервер и не включайте весь /etc без необходимости.

Выполните на VPS:

sudo tar -czf /home/admin/vps-example-2026-09-05.tar.gz \
  /etc/nginx/sites-available \
  /etc/systemd/system \
  /var/www/example.org
sudo chown admin:admin /home/admin/vps-example-2026-09-05.tar.gz
sudo chmod 600 /home/admin/vps-example-2026-09-05.tar.gz

tar собирает несколько путей в один файл. Параметр -c создаёт архив, -z сжимает его gzip, -f задаёт имя. Обратная косая черта в конце строки продолжает одну команду на следующей строке.

Архив создаётся с административными правами, чтобы прочитать системные конфигурации. После этого chown передаёт файл пользователю admin, а режим 600 оставляет чтение и запись только владельцу. Замените пользователя, домен и дату.

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

Запишите контрольную сумму перед скачиванием

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

На VPS выполните:

sha256sum /home/admin/vps-example-2026-09-05.tar.gz

Сохраните строку результата рядом с локальной копией. Она содержит сумму и имя файла, но не раскрывает содержимое архива.

Большой размер не доказывает полноту копии. Он лишь помогает заметить очевидно пустой файл. Нужные данные подтверждаются просмотром содержимого и восстановлением.

Скачайте архив по SSH

Следующая команда выполняется на локальном компьютере. Она копирует архив в заранее подготовленный каталог backups:

scp admin@203.0.113.10:/home/admin/vps-example-2026-09-05.tar.gz ./backups/

Замените пользователя и IP-адрес. scp использует тот же защищённый SSH-доступ, что и терминал. После завершения файл должен появиться локально с ожидаемым размером.

В PowerShell вычислите локальную сумму командой Get-FileHash .\backups\vps-example-2026-09-05.tar.gz -Algorithm SHA256. В Linux или macOS используйте sha256sum либо shasum -a 256. Значение должно точно совпасть с сохранённой суммой VPS.

Просмотрите и распакуйте копию отдельно

Сначала покажите список файлов без извлечения. Команда tar доступна в современных Windows, macOS и Linux:

tar -tzf ./backups/vps-example-2026-09-05.tar.gz | head -n 50

Параметр -t показывает содержимое, -z читает gzip, -f указывает файл. В PowerShell, где head отсутствует, выполните tar -tzf .\backups\vps-example-2026-09-05.tar.gz | Select-Object -First 50.

Проверьте наличие ожидаемого файла Nginx, unit-файлов и каталога сайта. Затем создайте новый пустой локальный каталог и распакуйте копию только туда. Не извлекайте системные пути поверх рабочих файлов компьютера.

После распаковки откройте несколько конфигураций и убедитесь, что они относятся к нужному VPS. Если архив содержит секреты, ограничьте доступ к локальному каталогу и не отправляйте его в Git.

Удалите временный архив с сервера после проверки

Архив в домашнем каталоге VPS дублирует чувствительные данные и занимает место. Удаляйте его только после трёх подтверждений: файл скачан, сумма совпала, пробная распаковка прошла.

Сначала проверьте точный путь, затем удалите один конкретный файл:

ls -l /home/admin/vps-example-2026-09-05.tar.gz
rm /home/admin/vps-example-2026-09-05.tar.gz

Пользователь admin уже является владельцем, поэтому sudo не требуется. Команда не использует шаблон и не затрагивает другие архивы. Локальную копию и сохранённую сумму оставьте.

Что проверить при восстановлении

Пробная распаковка подтверждает целостность архива, но ещё не весь процесс восстановления. Отдельно запишите:

1. Как установить поддерживаемый выпуск Ubuntu и нужные пакеты.
2. Из какого Git commit собрать сайт.
3. Куда вернуть конфигурацию Nginx и unit-файлы.
4. Где получить секреты, которые не входят в обычный архив.
5. Как восстановить базу и пользовательские загрузки.
6. Какими локальными и внешними запросами проверить результат.

Не направляйте рабочий домен на тест восстановления. Проверяйте файлы в отдельном каталоге или на временном VPS, когда это потребуется и будет согласовано.

GitHub-репозиторий ускоряет возврат исходников, а каталоги выпусков — возврат предыдущей версии сайта. Ни один из них не сохраняет весь сервер автоматически. Проверенная локальная копия закрывает конфигурации и уникальные данные, которые были явно включены в процедуру.

Этим этапом завершается основная часть маршрута «VPS с нуля»: сервер публикует сайт, владелец умеет найти сбой и может по запросу скачать проверяемую копию на свой компьютер.

Первоисточники

• GNU tar: создание и извлечение архивов
• OpenSSH: передача файлов через scp
• GNU Coreutils: sha256sum
• systemd: проверка состояния служб