Чек-лист обслуживания Linux-сервера: еженедельные проверки

Что на самом деле означает обслуживание Linux-сервера

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

Создание сервера — это другая задача, и первые десять минут на новом VPS охватывают именно её. Эта страница посвящена следующему году эксплуатации. Каждый пункт ниже называет сбой, который он предотвращает, поскольку контрольный список без понимания последствий — это то, что люди перестают использовать.

Приведенные здесь команды носят иллюстративный характер и предназначены для ознакомления перед запуском. Сравнивайте их вывод с состоянием вашего сервера, так как нормальные значения свободного места или количества процессов зависят от задач конкретной машины. Там, где проверка различается в зависимости от дистрибутива, об этом сказано в тексте. В примерах используются Debian и Ubuntu с apt. В семействе RHEL инструментарий представлен dnf, а некоторые пути отличаются.

Как выбрать график обслуживания Linux-сервера, которого вы сможете придерживаться

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

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

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

Назначьте выполнение задач на фиксированное время: утро понедельника для еженедельного обхода и первое число месяца для ежемесячного. Чек-лист, который выполняется «когда дойдут руки», не является чек-листом. Если у вас больше нескольких машин, запускайте эти проверки из одного места, а не вручную, что является темой управления несколькими Linux-серверами из одного центра.

Еженедельная проверка: действительно ли установлены обновления?

Включение unattended-upgrades не означает, что обновления были выполнены. Сервис может быть заблокирован (masked), конфигурация может быть ограничена репозиторием, который вы не используете, а один зафиксированный (held) пакет может прервать выполнение всех последующих задач. Установка описана в автоматические обновления безопасности в Ubuntu. Еженедельная задача нужна для подтверждения того, что установленное ПО выполнило свою работу.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable — это объективный показатель, так как он отражает текущее состояние системы, а не намерения администратора. Если обновления безопасности всё ещё присутствуют в списке, значит, автоматизация не работает. Прочитайте журнал (log), прежде чем считать, что система защищена. Пакет, зафиксированный с помощью apt-mark hold, будет пропускаться постоянно и не вызовет никаких уведомлений, поэтому apt-mark showhold следует выполнять в рамках той же проверки.

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

Еженедельно: запас места на диске и свободных inode

Заполнение корневой файловой системы приводит к сбоям в работе компонентов, которые на первый взгляд не связаны с дисковым пространством. База данных перестает принимать записи, логирование прекращается, обновление пакетов прерывается на середине, а в некоторых конфигурациях невозможно открыть новую сессию, так как система не может записать временные файлы.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i — это аспект, который многие упускают из виду. Inode — это структуры с фиксированным количеством, в которых хранятся метаданные файлов. Файловая система может исчерпать их, даже если df -h по-прежнему показывает наличие свободных гигабайт. В этом случае запись завершается ошибкой No space left on device, несмотря на отчет о свободном месте, что в первый раз приводит к потере часа времени на диагностику. Чаще всего это происходит из-за миллионов мелких файлов, например, в зависшей очереди почтового сервера или в директории сессий, которую никто не очищает.

du -xh работает в рамках одной файловой системы, что необходимо на серверах с bind mounts или подключенными внешними накопителями. На хосте с Docker проблема обычно кроется в слоях образов и неиспользуемых томах, которые очищаются согласно инструкции очистка дискового пространства Docker на VPS.

Свободное место показывает текущую емкость. Физический носитель может выйти из строя по собственному графику, поэтому проверка состояния диска — это отдельная задача, описанная в мониторинг состояния дисков на VPS.

Еженедельная проверка: что остановилось без уведомления?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Юнит, который завершился с ошибкой и достиг лимита перезапусков, переходит в состояние failed и остаётся в нём, не подавая сигналов. Никаких уведомлений по электронной почте об этом не приходит. Команда list-timers — более полезная часть: она показывает, когда каждый таймер запускался в последний раз и когда сработает в следующий, поэтому значение LAST, превышающее интервал самого таймера, означает, что задача не выполнялась вовсе.

Перед перезапуском юнита изучите журнал с помощью journalctl -u <unit> -n 100 --no-pager. Перезапуск устраняет симптом, и у вас не будет повода разобраться в проблеме, пока она не повторится в менее подходящее время.

Это предотвращает сбои, при которых агент мониторинга, обработчик очереди или служба резервного копирования остаются нерабочими после скачка потребления памяти, произошедшего три недели назад.

Еженедельно: действительно ли завершилось задание резервного копирования?

Запланированное резервное копирование и завершенное резервное копирование — это разные вещи, и восстановить данные можно только из завершенного. Проверяйте факт завершения.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

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

Если ваш скрипт передает дамп в архиватор через конвейер, добавьте set -o pipefail в начало файла. Без этого параметра статус завершения всего конвейера будет определяться статусом архиватора, а архиватор выполнил свою задачу успешно: он сжал сообщение об ошибке. В результате задание каждую ночь отчитывается об успехе, записывая при этом пустой архив минимального размера.

Ежемесячно: восстановление резервной копии на другом узле

Это пункт, который пропускает большинство администраторов, и именно он определяет, имело ли смысл всё остальное из этого списка.

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

Инструменты для работы с репозиториями имеют собственные средства проверки: restic check --read-data-subset=5% и borg check --verify-data считывают сохранённые данные, а не индекс. Запускайте их, но рассматривайте это как предварительное тестирование, а не как полноценную замену. Верификация проверяет сохранность байтов. Восстановление проверяет, что эти байты — именно те, которые нужны вашему приложению.

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

Ежемесячно: какие сертификаты скоро истекают?

Автоматизация обновления может завершаться с ошибкой без уведомлений. Таймер certbot может обновить файл на диске, в то время как веб-сервер продолжит отдавать старый сертификат из оперативной памяти, так как скрипт deploy hook, отвечающий за перезагрузку сервиса, не был выполнен. Поэтому запрашивайте у работающего сервера информацию о том, какой сертификат он использует, извне.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Флаг -servername устанавливает SNI (server name indication), который необходим на любом адресе, где размещено более одного сайта; в противном случае вы получите сертификат по умолчанию, а не свой. Если certbot был установлен через snap, таймер называется иначе, поэтому ищите по ключевому слову, а не по предполагаемому имени юнита.

Не забывайте о сертификатах, для которых автоматизация вообще не настроена: почтовый сервер, VPN, внутренняя инфраструктура открытых ключей (CA). Именно они истекают в выходные дни, после чего браузеры и клиенты полностью блокируют доступ к ним, а не просто выводят предупреждение.

Ежемесячно: пользователи, доступ sudo и SSH-ключи

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T выводит итоговую конфигурацию после объединения всех Include, которую демон фактически использует в работе. В современных образах Ubuntu файлы настроек размещаются в /etc/ssh/sshd_config.d/, и они могут переопределять основной файл, поэтому чтение только sshd_config может привести к неверным выводам. В семействе RHEL административной группой является wheel, а не sudo, поэтому скорректируйте строку getent.

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

Для просмотра истории входов journalctl -t sshd --since "30 days ago" | grep -i accepted выполняет поиск по идентификатору syslog, а не по имени юнита. Это важно, так как Ubuntu 24.04 активирует SSH через сокет, поэтому каждое соединение регистрируется под сгенерированным юнитом для конкретного подключения, и обычный journalctl -u ssh может их пропустить.

Ежемесячно: старые ядра и переполнение /boot

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

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r — это первое, что нужно сделать: команда показывает ядро, которое используется в данный момент, и его нельзя удалять ни при каких обстоятельствах. apt autoremove справляется с типичными ситуациями в Debian и Ubuntu, так как ядра помечаются как установленные автоматически, а текущее ядро защищено от удаления. Нестандартные случаи, такие как вручную установленное ядро или раздел /boot, заполненный настолько, что это блокирует работу apt, описаны в очистке старых ядер в Ubuntu.

Ежемесячно: рост логов и журнал systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

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

Размер журнала ограничен systemd, но это ограничение вычисляется как доля от объема файловой системы, а не как заданное вами число. Установите SystemMaxUse= в файле /etc/systemd/journald.conf и перезапустите systemd-journald, если вам нужен фиксированный предел. Команда sudo journalctl --vacuum-time=14d освобождает место немедленно; это разовая операция, а не политика, поэтому используйте её вместе с изменением конфигурации.

После обновления: перезагрузка, которую вы откладываете

Обновленный пакет ядра на диске — это еще не работающее ядро. До перезагрузки машина продолжает использовать старую версию, а live patching, где он доступен, покрывает лишь часть исправлений.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Этот файл-флаг является соглашением в Debian и Ubuntu, создаваемым скриптами пакетов. В системах семейства RHEL он не создается, а на аналогичный вопрос там отвечает needs-restarting -r, который входит в состав dnf-utils. Утилита needrestart, установленная по умолчанию в современных образах Ubuntu Server, отвечает за уровень ниже ядра: она выводит список процессов, которые все еще используют библиотеки, замененные на диске. Именно поэтому обновленный OpenSSL не начнет действовать, пока не будут перезапущены использующие его сервисы.

Планируйте перезагрузку, а не избегайте её. В /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; и Unattended-Upgrade::Automatic-Reboot-Time "03:00"; вы можете назначить выполнение этой задачи на выбранное время. Плановая перезагрузка — это также единственный способ проверить, вернется ли сервер в рабочее состояние, так как некорректная запись в fstab или сервис, который вы забыли включить, проявят себя только при загрузке системы.

Планирование обновления дистрибутива для каждого релиза

Релизы Ubuntu LTS получают пять лет стандартной поддержки, а промежуточные релизы — девять месяцев, поэтому ваш выбор определяет объем работ по обновлению на годы вперед. Этот компромисс описан в LTS против промежуточных релизов на сервере.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade считывает этот файл, а Prompt=lts ограничивает его только переходами между LTS-версиями. Путь обновления LTS-to-LTS обычно открывается с выходом первого точечного релиза новой версии, а не в день основного релиза, поэтому проверяйте, что именно предлагается вашей системе, вместо того чтобы планировать обновление на предполагаемую дату. Механика перехода описана в обновлении Ubuntu 24.04 до 26.04.

Заложите три месяца в качестве резервного времени. Сделайте снапшот и убедитесь, что вы умеете его восстанавливать, составьте список сторонних apt-репозиториев (процесс обновления отключает их, и для каждого потребуется новый целевой адрес под новый релиз) и определите план отката до начала работ. По состоянию на август 2026 года, Ubuntu 24.04 LTS имеет стандартную поддержку до апреля 2029 года, поэтому речь идет о плановом обслуживании, а не об экстренной ситуации.

Что автоматизировать, а что оставить на ручном управлении

Автоматизируйте решения, которые вы уже приняли: обновления безопасности, ротацию логов, продление сертификатов и задания по резервному копированию. Также автоматизируйте оповещения, так как проверка, зависящая от того, вспомните ли вы о ней, — это проверка, которая не будет выполнена в 2 часа ночи. Внешний мониторинг, например self-hosted мониторинг состояния с помощью Uptime Kuma, позволяет отследить то, о чем не сообщит ни один локальный скрипт: недоступность самого сервера.

Две вещи оставьте на ручном управлении: проверку восстановления из бэкапа и аудит учетных записей. В обоих случаях требуется человек, который решит, является ли результат корректным. Если вам удобнее просматривать состояние системы в браузере, а не в терминале, сравнение Cockpit и Webmin для управления сервером поможет выбрать одну из двух популярных веб-консолей.

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

Чек-лист в одном месте

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Как часто нужно проводить обслуживание Linux-сервера?

Еженедельно для всего, что меняется самостоятельно: статус обновлений, свободное место на диске и количество свободных inode, упавшие юниты и успешность выполнения резервного копирования. Ежемесячно для отслеживания медленной деградации: тест восстановления, срок действия сертификатов, аудит учетных записей и SSH-ключей, удаление старых ядер, рост логов. Один раз за цикл выпуска дистрибутива — для обновления версии и перезагрузки в актуальное ядро. Еженедельная проверка на исправной машине занимает несколько минут; именно поэтому её стоит проводить регулярно, а не только при возникновении видимых проблем.

Зачем тестировать восстановление, если задача резервного копирования сообщает об успехе?

Потому что задача сообщает лишь о собственном коде завершения, который может быть успешным, даже если архив бесполезен. Дамп, переданный через конвейер в архиватор без set -o pipefail, возвращает статус архиватора. В результате неудачный дамп, который выдал только сообщение об ошибке, завершается с кодом 0 и создает пустой или поврежденный файл. Выполните восстановление на другой машине, откройте данные и проверьте их целостность. Процесс восстановления также позволяет замерить время, которое и будет вашим реальным временем восстановления (RTO).

Нужно ли перезагружать сервер после каждого обновления ядра?

Перезагрузка необходима для того, чтобы система начала использовать новое ядро. В Debian и Ubuntu наличие файла /var/run/reboot-required означает, что пакет запросил перезагрузку, а /var/run/reboot-required.pkgs указывает, какой именно. В семействе RHEL такого файла нет, и на тот же вопрос отвечает needs-restarting -r из пакета dnf-utils. Настройте окно автоматической перезагрузки в /etc/apt/apt.conf.d/50unattended-upgrades вместо того, чтобы откладывать её на неопределенный срок: машина, которая не перезагружалась год, имеет не только устаревшее ядро, но и непроверенный процесс загрузки.

Какие из этих проверок можно безопасно автоматизировать?

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