Сервер после настройки кажется вещью, которую поставил и забыл. Но система, которую полгода не трогали, накапливает известные уязвимости, логи съедают диск, сертификат однажды не продлевается, а бэкап, как выясняется в день аварии, перестал создаваться ещё весной. Регулярное обслуживание занимает 15–30 минут в месяц, если делать его по списку. Ниже — такой список: что проверять раз в неделю, раз в месяц, раз в квартал и раз в год, с командами для Debian и Ubuntu.
Предполагается, что базовая настройка уже сделана: свой пользователь, вход по ключу, файрвол, fail2ban и автоматические обновления безопасности. Если нет — начните со статьи «Как настроить VPS после покупки».
Регламент одной таблицей
| Как часто | Что делать | Время |
|---|---|---|
| Раз в неделю | Диск, память, упавшие службы, входы на сервер | 5 минут |
| Раз в месяц | Обновления, перезагрузка, сертификаты, приложение, бэкапы | 15–30 минут |
| Раз в квартал | Пробное восстановление из бэкапа, ревизия доступов и портов | 1 час |
| Раз в год | Срок поддержки системы, тариф, план переезда | 1 час |
Большую часть еженедельных проверок можно отдать мониторингу: он сам сообщит о заполненном диске или упавшей службе. Но раз в неделю взглянуть своими глазами всё равно полезно — мониторинг проверяет только то, что в него заложили.
Раз в неделю: пять минут
Диск
df -h # место на разделах df -i # inode: кончаются при миллионах мелких файлов du -xh / --max-depth=2 2>/dev/null | sort -h | tail -15
Последняя команда показывает, какие каталоги занимают больше всего. Типичные пожиратели места: логи, старые бэкапы на том же диске, кэш пакетов, образы и тома Docker, временные файлы сессий.
Отдельно — системный журнал, который на маленьком диске может занять гигабайты:
journalctl --disk-usage journalctl --vacuum-size=300M
Чтобы он не разрастался снова, задайте предел в /etc/systemd/journald.conf: SystemMaxUse=300M, затем systemctl restart systemd-journald.
Память и службы
free -h systemctl --failed
Если своп используется постоянно и растёт — где-то утечка памяти или серверу не хватает ресурсов. systemctl --failed покажет службы, которые упали и не поднялись: иногда это что-то важное вроде задания бэкапа.
Кто заходил на сервер
last -n 20 journalctl -u ssh --since "7 days ago" | grep Accepted
Все успешные входы должны быть вашими: ваши ключи, ваши IP, ваше время. Незнакомый вход — повод разбираться немедленно, а не в конце месяца.
Раз в месяц: 15–30 минут
Обновления системы
Исправления безопасности ставятся автоматически, но остальные обновления копятся. Раз в месяц, в спокойное время и после свежего бэкапа:
sudo apt update apt list --upgradable sudo apt upgrade sudo apt autoremove --purge
Перед установкой просмотрите список: обновление основной версии базы данных или PHP лучше делать отдельно и обдуманно, а не попутно.
Перезагрузка, если нужна
Обновлённое ядро и системные библиотеки начинают работать только после перезагрузки. Система выглядит обновлённой, а уязвимость продолжает работать. Проверка:
ls /var/run/reboot-required 2>/dev/null && echo "нужна перезагрузка" sudo needrestart -r l # какие службы используют старые библиотеки
Файл reboot-required создаётся в Ubuntu; в Debian ориентируйтесь на needrestart (ставится одноимённым пакетом). Перезагружайте в тихие часы, но не откладывайте на месяцы.
Сертификаты
sudo certbot certificates sudo certbot renew --dry-run
Срок у сертификатов Let's Encrypt будет сокращаться (64 дня с февраля 2027 года, 45 — с февраля 2028-го), а писем об истечении больше нет. Поэтому раз в месяц проверьте, что автопродление проходит. Подробнее — в статье «SSL на VPS».
Приложение
Система и сайт обновляются независимо. Движок, плагины, темы, библиотеки — ваша ответственность, и уязвимости в них используют чаще, чем дыры в самой системе: устаревший плагин популярной CMS находят автоматические сканеры. Раз в месяц обновите CMS и плагины (сначала на копии, если сайт важный), удалите неиспользуемые.
Бэкапы: создаются ли
Посмотрите на дату последней копии на сервере бэкапов и её размер. Копия, которая неделю не обновлялась или вдруг стала в десять раз меньше, — тревожный знак. Ещё лучше поручить эту проверку мониторингу.
Docker, если используется
docker system df docker image prune -a --filter "until=720h"
Старые образы после обновлений остаются на диске и незаметно съедают десятки гигабайт. Вторая команда удаляет неиспользуемые образы старше 30 дней. Тома с данными (docker volume prune) чистите осторожно: там может лежать база.
Раз в квартал: час
Пробное восстановление
Самая важная проверка из всех. Бэкап, из которого ни разу не восстанавливались, — это надежда, а не бэкап. Раз в квартал разверните копию на временном сервере: поднимите сайт, откройте пару страниц, проверьте, что база на месте и свежая. Заодно засеките время — вы будете знать, сколько займёт восстановление в настоящей аварии. Временный сервер можно взять на месяц и удалить. Как устроить копирование — в статье «Сервер для бэкапа».
Ревизия доступов
getent passwd | awk -F: '$3 >= 1000 {print $1}' # пользователи
getent group sudo # у кого есть sudo
cat ~/.ssh/authorized_keys # чьи ключи могут войти
Учётные записи ушедших подрядчиков и забытые ключи живут годами, а вспоминают о них после инцидента. Удалите всё, что не используется. Заодно смените пароли от панели провайдера, базы данных и CMS, если ими пользовался кто-то ещё.
Открытые порты
sudo ss -tulpn sudo ufw status verbose
Наружу должно смотреть только то, что должно: обычно SSH, 80 и 443. База данных, Redis, панели администрирования, порты метрик — только на 127.0.0.1 или для конкретных IP. Открытая наружу база без пароля — классическая причина утечек.
Раз в год: час
Срок поддержки системы
cat /etc/os-release
У каждой версии Debian и Ubuntu есть дата окончания поддержки, после которой исправления безопасности перестают выходить. Ориентиры: Ubuntu 22.04 получает стандартные обновления до апреля 2027 года, 24.04 — до 2029-го; Debian 12 в июне 2026 года перешёл на долгосрочную поддержку силами сообщества (LTS) до 2028 года, актуальная версия — Debian 13. Запишите дату для своей системы и запланируйте переход за полгода, а не узнавайте о нём из новостей.
Обновление на новую версию «на месте» возможно, но для важного сервера спокойнее другой путь: взять новый VPS на свежей системе, перенести сайт и переключить DNS. Старый сервер остаётся запасным, пока не убедитесь, что всё работает. Пошагово — в статье «Как перенести сайт на VPS без простоя».
Тариф и площадка
Посмотрите на графики за год: если память стабильно занята на 80–90%, а диск растёт — пора на старший тариф, пока это не стало аварией. Если ресурсы почти не используются — можно перейти на младший. Как прикинуть нужное — в статье «Как выбрать тариф VPS».
Еженедельная сводка одним скриптом
Чтобы не набирать команды руками, соберите их в скрипт /usr/local/bin/server-check:
#!/bin/sh echo "== Диск"; df -h -x tmpfs -x devtmpfs echo "== Память"; free -h echo "== Упавшие службы"; systemctl --failed --no-legend echo "== Обновления"; apt list --upgradable 2>/dev/null | tail -n +2 | wc -l [ -f /var/run/reboot-required ] && echo "== Нужна перезагрузка" echo "== Входы за неделю"; journalctl -u ssh --since "7 days ago" | grep -c Accepted
sudo chmod +x /usr/local/bin/server-check server-check
Его можно запускать по расписанию через cron и отправлять вывод себе на почту или в Telegram, но проще и надёжнее отдать постоянные проверки системе мониторинга, а скрипт использовать для быстрого взгляда.
Где держать бэкапы и мониторинг
Обе вещи должны жить отдельно от основного сервера: копия и проверка на той же машине пропадут вместе с ней. Младшего тарифа в другой стране хватит и на хранение копий небольшого проекта, и на Uptime Kuma.
Lite в Нидерландах под бэкапы и мониторинг — $6/мес Lite в Финляндии — $6/мес
Цены указаны на момент публикации, оплата у провайдера. У провайдера есть и готовые услуги: хранение бэкапов и мониторинг доступности.
Коротко
- Раз в неделю: диск, журнал, память, упавшие службы, входы по SSH.
- Раз в месяц: обновления и перезагрузка, сертификаты, CMS и плагины, свежесть бэкапов, чистка Docker.
- Раз в квартал: пробное восстановление из бэкапа, ревизия пользователей, ключей и открытых портов.
- Раз в год: срок поддержки системы, план переезда на новую версию, проверка тарифа.
- Постоянные проверки отдайте мониторингу на отдельном сервере.