Перелік завдань щомісячного обслуговування Linux-сервера

Правильно налаштований з самого початку Linux-сервер може місяцями працювати без помітних проблем, а всі сервіси на ньому можуть функціонувати цілком стандартно. Сайти відкриваються, база даних відповідає, SSH доступний і ніяких проблем, здавалося б, не спостерігається. Тим часом розмір логів на сервері постійно зростає, накопичуються оновлення, закінчуються inode, залишаються старі та неактуальні SSH-ключі тощо. Тобто з часом ваш сервер у будь-якому разі буде захаращуватися.

Тому приблизно раз на місяць буде корисно перевірити сервер і оцінити його роботу - від загального стану системи до додатків і резервних копій. По-хорошому така перевірка не повинна перетворюватися на багатогодинний аудит, тобто всі кроки мають бути простими й зрозумілими, а от результат має бути зрозумілим і передбачуваним.

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

 

 

 

 

Крок 1. Перевіряємо поточний стан сервера

Як і в будь-якій справі, краще починати з розуміння загальної картини, перш ніж кидатися щось оновлювати та перезапускати сервіси. Для цього використовується набір стандартних команд:

uptime
free -h
df -h
df -i
systemctl --failed
timedatectl

Тут нас насамперед цікавлять навантаження, пам'ять і swap, вільне місце, inode, systemd-одиниці, що вийшли з ладу, та правильність системного часу.

Щодо цифр, правда, є нюанс. Наприклад, зайнята оперативна пам'ять сама по собі мало про що говорить, оскільки Linux активно використовує пам'ять під кеш. Набагато корисніше буде порівнювати поточний стан із звичайним станом саме цього сервера.

Те саме стосується й диска. Наприклад, каталог/var, який стабільно займає 70 ГБ, може бути цілком нормальним явищем. А ось зростання його обсягу з 35 до 70 ГБ за кілька місяців - це вже привід шукати причину.

 

 

 

 

Крок 2. Дивимося, що відбувалося протягом місяця

Коли ми дивимося на поточний стан сервера, це нічого не говорить нам про стан системи навіть у недалекому минулому. Адже сервер міг мати якісь проблеми кілька тижнів тому, а зараз виглядати цілком здоровим. Тому обов’язковим етапом такого аудиту є перевірка основних журналів сервера на наявність нестандартних подій у минулому:

journalctl -p warning..alert --since "30 days ago"
journalctl -k -p warning..alert --since "30 days ago"

 

І окремо пошукаємо події OOM (Out Of Memory):

journalctl -k --since "30 days ago" | grep -Ei "oom|out of memory|killed process"

 

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

OOM теж легко пропустити, адже сьогодні на сервері може бути кілька гігабайтів вільної оперативної пам’яті, хоча тиждень тому ядро, наприклад, завершило роботу PostgreSQL або PHP-FPM через брак пам’яті.

 

 

 

 

Крок 3. Перевіряємо оновлення

Оновлення Linux-дистрибутивів виходять постійно. У них виправляються виявлені помилки, усуваються виявлені вразливості, оновлюються системні бібліотеки та окремі компоненти системи. На сервері, що працює вже давно, частина таких пакетів може місяцями залишатися у старій версії, особливо якщо автоматична установка оновлень не була налаштована.

Тому під час щомісячного обслуговування варто перевірити, які оновлення доступні. Відразу встановлювати все підряд необов’язково, і для початку потрібно переглянути список пропонованих пакетів, щоб зрозуміти, що саме зміниться.

Для Debian та Ubuntu це можна зробити за допомогою команд:

apt update
apt list --upgradable

 

Для систем на кшталт RHEL:

dnf check-update

 

У першу чергу в отриманому списку необхідно звернути увагу на ядро, OpenSSH, системні бібліотеки, СКБД, веб-сервер та ПЗ, яке приймає з’єднання з Інтернету, оскільки вразливості найчастіше виявляються саме там.

Безумовно, критичні оновлення безпеки потрібно встановлювати одразу після їх виходу, не відкладаючи до планового обслуговування. А під час такої щомісячної перевірки достатньо лише подивитися, які оновлення накопичилися з минулого разу та які з них потрібно встановити.

 

Після встановлення пакетів у Debian та Ubuntu перевіримо, чи потрібне перезавантаження:

test -f /var/run/reboot-required && cat /var/run/reboot-required

 

Поточне ядро можна перевірити окремо за допомогою команди:

uname -r

 

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

 

 

 

 

Крок 4. Перевіряємо диски та журнали

Дисковий простір на сервері постійно витрачається, оскільки системні журнали постійно й безперервно зростають, додатки створюють тимчасові файли, після оновлень залишаються старі пакети та ядра тощо. І якщо вільне місце на диску вашого сервера закінчується, то проблеми можуть виникнути одразу у кількох класах сервісів - від бази даних до веб-сервера. Тому під час щомісячної перевірки корисно подивитися, які каталоги зростають швидше, ніж зазвичай, і скільки місця займають журнали. Ну і, за необхідності, їх очистити.

Тепер розберемося, куди саме йде місце.

du -xhd1 /var | sort -h
journalctl --disk-usage

 

Якщо збільшився /var/log, то дивимося вже всередині цього каталогу детальніше:

du -xhd1 /var/log | sort -h

 

Якщо ви знайшли якийсь великий лог, то не поспішайте його видаляти. Спочатку знайдіть джерело, яке записує в цей лог, і з’ясуйте, чому програма записує стільки даних і чи працює ротація.

Заодно перевірте каталог /boot, старі архіви, тимчасові файли та налаштування утиліти logrotate, яку ми настійно рекомендуємо використовувати.

 

А як її встановити та налаштувати - читайте в цій статті.

Також під час аналізу логів варто пам’ятати про таку особливість: команда du може не відображати файли, які, здавалося б, були видалені, але якийсь процес продовжує тримати їх відкритими. У результаті місце на диску залишається зайнятим. Переглянути такі файли краще за допомогою команди:

lsof +L1

Якщо там виявився величезний видалений файл, то спробуйте знайти процес, що утримує його, і перезапустити його стандартними засобами.

 

 

 

 

Крок 5. Перевіряємо фонові завдання

Багато регулярних операцій на сервері виконуються автоматично і зазвичай не вимагають уваги адміністратора. Такі завдання, як резервне копіювання, поновлення сертифікатів, очищення тимчасових файлів та різні скрипти технічного обслуговування, можуть місяцями працювати за розкладом, не привертаючи особливої уваги. Проблеми можуть виникнути в тому випадку, якщо одне з таких завдань з якоїсь причини перестає виконуватися, а помітних наслідків спочатку немає.

Для перевірки запланованих завдань (systemd timers) використовуйте команду:

systemctl list-timers --all

 

Перевірте час останнього запуску важливих завдань та дату наступного запуску; якщо якесь завдання давно не виконувалося або має дивний розклад, то обов’язково варто перевірити відповідний сервіс та його журнал.

Для cron перевірте самі завдання та їхнє фактичне виконання за логами. Особливу увагу варто приділити резервному копіюванню, автоматичним скриптам обслуговування та іншим завданням, від яких залежить робота сервера.

Тільки пам’ятайте, що сам факт наявності певного рядка в crontab ще не означає, що скрипт успішно запускається, адже він може завершуватися з помилкою, не мати потрібних прав або звертатися до недоступного файлу, що призводить до його збою. Тому тут нас цікавить саме результат останнього виконання завдання. До речі, про налаштування cron у нас є окрема коротка стаття.

 

 

 

 

Крок 6. Проводимо швидку перевірку безпеки

Навіть якщо сервер працює стабільно, раз на місяць все одно буде корисно перевірити, хто має до нього доступ і які сервіси доступні з мережі. З часом можуть залишатися старі облікові записи, забуті SSH-ключі або відкриті порти, які більше не потрібні. Звичайно, проводити повний аудит безпеки системи щомісяця - надмірно. А ось для щомісячної простої перевірки достатньо кількох простих стандартних команд:

last
ss -lntup
getent group sudo

Ці команди відображають інформацію про:

• останні входи та невідомі підключення;
• користувачів з адміністративними правами;
• старі облікові записи та SSH-ключі;
• відкриті порти;
• правила брандмауерів - UFW, firewalld або nftables.

 

Список відкритих портів обов’язково потрібно звірити з сервісами, які дійсно мають бути доступними на цьому сервері. Якщо раптом виявився незнайомий порт або користувач, то спершу з’ясуйте, звідки він з’явився і чи потрібен він зараз.

Особливо корисно перевірити права доступу після завершення роботи підрядників або тимчасових співробітників, оскільки старий SSH-ключ легко переживає людину, якій його колись видали.

Ну і, звісно, якщо під час такої базової перевірки ви виявили якісь підозрілі "докази" - тоді обов’язково потрібно провести повноцінний аудит безпеки сервера, щоб усунути можливість компрометації системи.

 

 

 

 

Крок 7. Перевіряємо додатки

Сама Linux-система - це лише операційна система, і вона цілком може працювати нормально, тоді як проблема виникає на рівні того чи іншого додатка.

Для веб-серверів Nginx або Apache обов’язково потрібно переглянути журнал помилок та файли конфігурації. Для баз даних PostgreSQL або MariaDB - перевірити стан сервісу, помилки, обсяг даних і вільне місце на диску. Конкретний набір перевірок, очевидно, залежить від кінцевих завдань сервера і, відповідно, від набору встановленого ПЗ.

Так, наприклад, якщо ви використовуєте Docker, то варто переглянути перелік зупинених контейнерів і використання дискового простору:

docker ps -a
docker system df

А ось автоматично запускати docker system prune -a за розкладом - це погана й згубна звичка, адже спочатку потрібно розібратися, які дані дійсно більше не потрібні, і лише потім видаляти їх. Ну а в роботі з volumes потрібна особлива обережність.

 

Перевіряємо TLS

Окремим класом є всілякі сертифікати. Навіть при автоматичному поновленні сертифікатів корисно іноді перевірити, що сервер насправді надає клієнту. Для цього використовуйте таку команду:

echo | openssl s_client -connect example.com:443 \
-servername example.com 2>/dev/null | \
openssl x509 -noout -dates

Так перевіряється саме активний на даний момент сертифікат, адже файл на диску міг оновитися, а ось веб-сервер з якоїсь причини може продовжувати використовувати старий сертифікат.

А ось контроль терміну дії сертифікатів краще винести в систему моніторингу та налаштувати сповіщення, щоб дізнаватися про проблему заздалегідь і встигнути оновити сертифікати до того, як сайт перестане відкриватися.

 

 

 

 

Крок 8. Перевіряємо резервні копії

Резервне копіювання має сенс лише тоді, коли дані з копії дійсно можна відновити. Ця думка здається очевидною, але дуже часто адміністратори просто складають резервні копії "в купку", а коли виникає необхідність терміново відновити дані з бекапу - цього просто не вдається зробити з тієї чи іншої причини, будь то невідповідні формати файлів або проблеми в самому процесі. Тому умовний зелений статус останнього бекапу - це лише половина перевірки.

Найкращим рішенням буде, якщо ви раз на місяць візьмете реальну резервну копію та спробуєте відновити її в ізольованому середовищі, наприклад на тимчасовій віртуальній машині, тестовому VPS або на окремому диску.

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

Також перевірте кілька останніх завдань резервного копіювання. Якщо одне із завдань завершилося з помилкою або почало виконуватися помітно довше, ніж зазвичай, то варто одразу з’ясувати причину.

Загляньте й у backup storage, оскільки вільне місце там теж має тенденцію закінчуватися, а переповнене сховище в якийсь момент просто перестане приймати нові копії.

 

 

 

 

Крок 9. Підбиваємо підсумки перевірки

Після такого базового щомісячного обслуговування обов’язково варто зафіксувати актуальний стан сервера. Детальний звіт для цього не потрібен, і достатньо просто записати кілька показників та виявлені проблеми, щоб під час наступної перевірки було з чим порівнювати.

 

Саму щомісячну перевірку можна звести до такої послідовності:

1. Перевірити load average, RAM, swap, диски та inode;
2. Переглянути failed units та системні помилки за місяць;
3. Знайти OOM та інші аварійні події;
4. Перевірити оновлення, ядро та необхідність перезавантаження;
5. Переглянути стан /var, /var/log, /boot та journal;
6. Перевірити cron, таймери systemd та ротацію логів;
7. Переглянути користувачів, SSH-ключі, порти та брандмауер;
8. Перевірити додатки, Docker та бази даних;
9. Перевірити TLS-сертифікати;
10. Переглянути результати резервного копіювання та виконати тестове відновлення;
11. Записати виявлені відхилення.

 

Для фіксації та відстеження історії перевірок достатньо невеликої таблиці в довільному форматі, наприклад:

Показник	Серпень	Вересень
/var	48 ГБ	61 ГБ
Сховище резервних копій	54%	67%
Сервіси з помилками	0	0
Події OOM	0	2

Такий запис допомагає побачити зміни з плином часу, які складно помітити під час разової перевірки. Наприклад, 61 ГБ, зайнятих у /var, самі по собі мало про що свідчать. А ось зростання цього показника з 48 до 61 ГБ за місяць уже вимагає пильної уваги. Те саме стосується й появи OOM-подій або швидкого заповнення сховища резервних копій.

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

Щоправда, періодична ручна перевірка при цьому все одно залишається корисною. Моніторинг, наприклад, повідомить, що каталог /var швидко зростає, а адміністратор зможе знайти причину такого стрімкого зростання. Або ось система резервного копіювання покаже успішне виконання завдання, а тестове відновлення підтвердить, що збереженими даними дійсно можна скористатися в надзвичайній ситуації.

 

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

 

 

FAQ або Поширені запитання

 

Як часто перевіряти Linux-сервер?

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

 

Чи потрібно щомісяця перезавантажувати сервер?

Ні. Перезавантажувати сервер просто за розкладом немає сенсу. Зазвичай це роблять після оновлення ядра або інших системних компонентів, яким для застосування змін потрібне перезавантаження. Тривалий час безперебійної роботи сам по собі не є проблемою.

 

Чи потрібно вручну очищати логи?

Зазвичай ні. За ротацію та видалення старих журналів відповідають logrotate, systemd-journald або сама програма. Якщо якийсь лог раптово зріс до кількох гігабайтів, спочатку з’ясуйте причину. Просте видалення файлу звільнить місце, але проблема незабаром з’явиться знову.

 

Як перевірити резервну копію?

Найнадійніший варіант - відновити її в ізольованому середовищі та перевірити дані, базу, права доступу й запуск програми. Успішне створення резервної копії ще не гарантує, що з неї вдасться відновити робочий сервер.

 

Що робити, якщо на сервері закінчується місце?

Спочатку з’ясуйте, який розділ і які каталоги розростаються. Часто причиною виявляються логи, тимчасові файли, старі архіви, дані Docker або накопичені резервні копії. Видаляти найбільші файли наосліп не варто - спочатку потрібно зрозуміти, навіщо вони потрібні й який процес їх створює.

 

Які проблеми можна виявити під час щомісячної перевірки?

Найчастіше виявляються речі, які поки що не заважають роботі сервера: накопичені оновлення, логи, що зростають, помилки фонових завдань, старі SSH-ключі або брак місця в backup storage. Така перевірка якраз і потрібна, щоб розібратися з ними до появи помітних наслідків.

 

Що з щомісячної перевірки краще автоматизувати?

Насамперед - контроль вільного місця, навантаження та пам’яті, доступності сервісів, помилок резервного копіювання, OOM та терміну дії TLS-сертифікатів. Якщо проблема вимагає реагування одразу після її виникнення, чекати наступної ручної перевірки немає сенсу.