Linux server onderhoud checklist: wekelijks en maandelijks

Wat Linux-serveronderhoud daadwerkelijk inhoudt

Linux-serveronderhoud is een korte lijst met controles die volgens een vast schema worden uitgevoerd; het is geen project met een einddatum. Wekelijks controleert u of updates zijn geïnstalleerd, of de schijf voldoende ruimte heeft, of er geen services zijn uitgevallen en of de back-uptaak is voltooid. Maandelijks test u een restore, controleert u de verloopdatum van certificaten, auditeert u accounts en sleutels, en verwijdert u oude kernels en logbestanden. Eén keer per distributierelease plant u de versie-upgrade en voert u de herstart uit die u steeds uitstelt.

Het bouwen van de server is een andere taak, en de eerste tien minuten op een nieuwe VPS behandelt dat onderdeel. Deze pagina gaat over het jaar daarna. Elk item hieronder benoemt het defect dat het voorkomt, omdat een checklist zonder gevolgen er een is die mensen stilletjes niet meer uitvoeren.

De commando's hier zijn illustratief en bedoeld om te worden gelezen voordat ze worden uitgevoerd. Vergelijk de uitvoer met uw eigen server, aangezien een gezonde waarde voor vrije ruimte of het aantal processen afhangt van de taken van de machine. Waar een controle verschilt tussen distributies, wordt dit in de tekst vermeld. Voorbeelden gebruiken Debian en Ubuntu met apt. Bij de RHEL-familie is de tooling dnf en zijn diverse paden anders.

Hoe u een onderhoudsschema voor Linux-servers kiest dat u volhoudt

Wekelijkse controles dekken zaken die zonder uw tussenkomst veranderen: pakketten, schijfgebruik, de status van services en geplande taken. Omdat deze processen autonoom verlopen, is een week ongeveer de maximale periode dat u ze onbeheerd kunt laten.

Maandelijkse controles dekken langzame achteruitgang: certificaten die bijna verlopen, accounts die niet zijn verwijderd, kernels die zich opstapelen in /boot, en logbestanden die groter worden dan de rotatieregels toelaten. Geen van deze zaken zorgt morgen voor problemen, maar uiteindelijk leiden ze allemaal tot een defect.

Release-controles zijn gebonden aan de kalender. Een distributie-release is het enige onderhoudspunt met een externe deadline, omdat de ondersteuning voor uw huidige versie afloopt, ongeacht of u er klaar voor bent.

Plan het onderhoud op een vast tijdstip: maandagochtend voor de wekelijkse ronde en de eerste dag van de maand voor de maandelijkse ronde. Een checklist die u "afwerkt wanneer het uitkomt" is geen checklist. Zodra u meer dan een handvol machines beheert, voert u deze taken vanaf één centrale plek uit in plaats van handmatig; dit is het onderwerp van het beheren van meerdere Linux-servers vanaf één locatie.

Wekelijks: zijn de updates daadwerkelijk geïnstalleerd?

Het inschakelen van unattended-upgrades is niet hetzelfde als weten dat het proces is uitgevoerd. De service kan gemaskeerd zijn, de configuratie kan beperkt zijn tot een bron die u niet gebruikt, en één vastgehouden pakket kan elke volgende uitvoering blokkeren. De installatie wordt behandeld in automatische beveiligingsupdates op Ubuntu. De wekelijkse taak is het bewijzen dat wat u heeft geïnstalleerd ook daadwerkelijk zijn werk heeft gedaan.

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 is de betrouwbare maatstaf, omdat deze de huidige status rapporteert in plaats van de intentie. Beveiligingsupdates die nog in die lijst staan, betekenen dat de automatisering niet naar behoren werkt; lees daarom het logbestand voordat u ervan uitgaat dat de machine is gepatcht. Een pakket dat is vastgezet met apt-mark hold wordt altijd overgeslagen en rapporteert niets, en daarom hoort apt-mark showhold in dezelfde reeks thuis.

De fout die dit voorkomt: maandenlang draaien met een pakket waarvan bekend is dat het kwetsbaar is, in de veronderstelling dat updates automatisch verliepen.

Wekelijks: schijfruimte en inode-capaciteit

Een vol root-bestandssysteem verstoort processen die op het eerste gezicht niets met schijfruimte te maken hebben. De database weigert schrijfacties, logging stopt, een pakket-upgrade wordt halverwege afgebroken en op sommige systemen kunt u geen nieuwe sessie openen omdat het systeem geen tijdelijke bestanden kan aanmaken.

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

df -i is het aspect dat de meeste mensen overslaan. Inodes zijn de structuren met een vast aantal die bestandsmetadata bevatten. Een bestandssysteem kan hierdoor uitgeput raken terwijl df -h nog steeds vrije gigabytes rapporteert. Schrijfacties falen vervolgens met No space left on device, terwijl de uitvoer van de schijfruimte nog voldoende vrije ruimte toont. Dit leidt de eerste keer tot verwarrende situaties. De oorzaak is meestal een enorm aantal kleine bestanden, bijvoorbeeld door een vastgelopen mailwachtrij of een sessiemap die niet wordt opgeschoond.

du -xh blijft beperkt tot één bestandssysteem, wat de gewenste werkwijze is op een server met bind mounts of gekoppelde opslag. Op een Docker-host ligt de oorzaak meestal in image-layers en ongebruikte volumes. Deze ruimt u op zoals beschreven in het opschonen van Docker-schijfgebruik op een VPS.

Vrije ruimte geeft inzicht in de capaciteit. De onderliggende opslag kan echter op elk moment falen; dit is een aparte controle die wordt behandeld in het monitoren van de schijfgezondheid op een VPS.

Wekelijks: wat is gestopt zonder melding?

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

Een unit die is gecrasht en de limiet voor herstarts heeft bereikt, blijft in de status failed staan zonder verdere actie. U ontvangt hierover geen e-mail. list-timers is het nuttigere onderdeel: het toont wanneer elke timer voor het laatst is uitgevoerd en wanneer deze de volgende keer wordt geactiveerd. Een LAST-waarde die ouder is dan het eigen interval van de timer, betekent dat de taak in het geheel niet is uitgevoerd.

Lees het logboek voor de unit met journalctl -u <unit> -n 100 --no-pager voordat u deze opnieuw start. Een herstart verhelpt het symptoom, maar daarna heeft u geen reden meer om onderzoek te doen totdat hetzelfde probleem zich op een ongelegen moment opnieuw voordoet.

Dit voorkomt het volgende defect: een monitoring-agent, een queue-worker of een back-upservice die al drie weken niet meer actief is sinds een piek in het geheugengebruik.

Wekelijks: is de back-uptaak daadwerkelijk voltooid?

Een geplande back-up en een voltooide back-up zijn verschillende zaken, en alleen de laatste is bruikbaar voor herstel. Controleer de voltooiing.

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

Bevestig twee zaken. De laatste uitvoering eindigde met exitcode 0, en het nieuwste archief is zowel recent als ongeveer van de verwachte grootte. Een back-upbestand dat plotseling een tiende van de gebruikelijke grootte heeft, is een mislukte dump die wel een bestand heeft geschreven. Dit is de gevaarlijkste vorm van back-upfalen, omdat alle processen die daarop volgen normaal lijken te verlopen.

Als uw script een dump doorstuurt naar een compressieprogramma, voeg dan set -o pipefail toe aan het begin van het script. Zonder deze optie is de exitstatus van de pipeline die van het compressieprogramma, en het compressieprogramma is geslaagd: het heeft de foutmelding gecomprimeerd. De taak rapporteert vervolgens elke nacht succes, terwijl er slechts een klein archief met niets wordt geschreven.

Maandelijks: herstel een back-up op een andere locatie

Dit is de stap die de meeste mensen overslaan, en het is de stap die bepaalt of de rest van de lijst zin had.

Herstel naar een andere machine of een nieuwe container; overschrijf nooit de actieve data. Open vervolgens wat u heeft hersteld en controleer of het authentiek is. Tel het aantal rijen in een tabel. Open een document. Log in op de herstelde applicatie. Een extractie die is voltooid, bewijst alleen dat het archief leesbaar is, niets meer dan dat.

Repository-tools hebben hun eigen verificatie: restic check --read-data-subset=5% en borg check --verify-data lezen de opgeslagen data in plaats van de index. Voer deze uit en beschouw ze als een eerste controle (smoke test) in plaats van een vervanging. Verificatie controleert of de bytes bewaard zijn gebleven. Een herstel controleert of de bytes de data zijn die uw applicatie nodig heeft.

Twee details die mensen vaak op de harde manier leren. Test de decryptie-passphrase op een machine die de sleutel nog niet in een agent heeft opgeslagen, want een back-up die u niet kunt ontsleutelen is geen back-up. Meet daarnaast de tijd van het herstel, want die duur is uw werkelijke hersteltijd (recovery time), en het gebruikelijke moment om die te ontdekken is tijdens een storing.

Maandelijks: welke certificaten verlopen binnenkort?

Automatisering van vernieuwingen faalt vaak onopgemerkt. De certbot timer kan het bestand op de schijf vernieuwen, terwijl de webserver het oude certificaat vanuit het geheugen blijft aanbieden. Dit gebeurt wanneer de deploy hook die de service herlaadt, niet is uitgevoerd. Vraag daarom van buitenaf aan de draaiende server welk certificaat deze aanbiedt.

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

De -servername flag stelt SNI (server name indication) in. Dit is vereist op elk adres dat meer dan één site host; anders ontvangt u het standaardcertificaat in plaats van het uwe. Als certbot via snap is geïnstalleerd, heeft de timer een andere naam. Zoek daarom op het woord in plaats van op een unit die u veronderstelde.

Denk aan de certificaten zonder enige automatisering: een mailserver, een VPN, een interne certificate authority. Dit zijn de certificaten die in het weekend verlopen, waarbij browsers en clients deze direct weigeren in plaats van een waarschuwing te geven.

Maandelijks: gebruikers, sudo-toegang en SSH-keys

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 toont de effectieve configuratie nadat elke Include is samengevoegd; dit is de configuratie die de daemon daadwerkelijk gebruikt. Recente Ubuntu-images bevatten drop-in-bestanden in /etc/ssh/sshd_config.d/, en deze kunnen het hoofdbestand overschrijven. Alleen sshd_config lezen kan u daarom op het verkeerde been zetten. Bij de RHEL-familie is de beheerdersgroep wheel in plaats van sudo, pas de getent-regel dus aan.

Lees vervolgens de authorized_keys-bestanden zelf. Toegang wordt verleend op basis van een key, niet op basis van een account. Een key die is achtergelaten door een externe medewerker die zes maanden geleden is vertrokken, is dus een werkende login die in geen enkele gebruikerslijst als risico wordt gemarkeerd. Keys bevatten een commentaarveld. Gebruik dit en verwijder alles wat u niet aan een persoon kunt toewijzen.

Voor de inloggeschiedenis matcht journalctl -t sshd --since "30 days ago" | grep -i accepted op de syslog-identifier in plaats van op een unit-naam. Dat is van belang omdat Ubuntu 24.04 SSH activeert via een socket. Elke verbinding wordt daardoor gelogd onder een gegenereerde unit per verbinding, en een standaard journalctl -u ssh kan deze missen.

Maandelijks: oude kernels en een volle /boot

/boot is op een standaard VPS-image vaak een aparte partitie van enkele honderden megabytes. Elke kernel-update voegt hier een image en een initramfs aan toe. Wanneer deze partitie vol raakt, mislukt de volgende upgrade halverwege en blijven pakketten ongeconfigureerd achter. Dit is een ongewenste situatie om op een vrijdag onverwacht aan te treffen.

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

uname -r eerst, altijd: dit commando toont de kernel die u op dit moment gebruikt, en deze mag onder geen beding worden verwijderd. apt autoremove handelt de standaardgevallen af op Debian en Ubuntu, aangezien kernels als automatisch geïnstalleerd worden gemarkeerd en de huidige kernel wordt beschermd. Uitzonderingen, zoals een handmatig geïnstalleerde kernel of een /boot die al zo vol is dat apt zelf wordt geblokkeerd, worden behandeld in het opschonen van oude kernels op Ubuntu.

Maandelijks: logboekgroei en het systemd journal

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

logrotate --debug is een dry run en schrijft geen wijzigingen weg, waardoor het veilig is op een productieserver. Het is raadzaam dit uit te voeren omdat rotatieregels gebaseerd zijn op paden: een applicatie die tijdens een upgrade de locatie van logbestanden heeft gewijzigd, valt niet langer onder de eigen regel. Hierdoor groeit het bestand ongehinderd totdat de schijf vol is.

Het journal wordt door systemd begrensd, maar op basis van een fractie van het bestandssysteem in plaats van een door u gekozen getal. Stel SystemMaxUse= in binnen /etc/systemd/journald.conf en herstart systemd-journald als u een specifiek maximum wilt instellen. sudo journalctl --vacuum-time=14d maakt direct ruimte vrij; dit is een eenmalige actie en geen beleid, dus combineer dit met de configuratiewijziging.

Per release: de reboot die u blijft uitstellen

Een bijgewerkt kernelpakket op schijf is niet hetzelfde als een actieve kernel. Totdat de machine opnieuw is opgestart, draait deze nog op de oude versie. Live patching, waar beschikbaar, dekt slechts een deel van de correcties.

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

Dat vlagbestand is een conventie van Debian en Ubuntu die door pakketscripts wordt aangemaakt. Systemen uit de RHEL-familie maken dit bestand niet aan; de equivalente vraag wordt daar beantwoord door needs-restarting -r, afkomstig uit dnf-utils. needrestart, dat standaard is geïnstalleerd op recente Ubuntu-serverimages, beantwoordt de vraag op een lager niveau dan de kernel: het geeft processen weer die nog steeds een bibliotheek in het geheugen hebben geladen die op schijf is vervangen. Dit is de reden waarom een gepatchte OpenSSL pas effect sorteert nadat de services die er gebruik van maken, zijn herstart.

Plan de reboot in plaats van deze te vermijden. In /etc/apt/apt.conf.d/50unattended-upgrades kunt u via Unattended-Upgrade::Automatic-Reboot "true"; en Unattended-Upgrade::Automatic-Reboot-Time "03:00"; het besluit delegeren naar een door u gekozen tijdstip. Een geplande reboot is bovendien de enige test om te zien of de machine weer opkomt, omdat een defecte fstab-vermelding of een service die u nooit hebt ingeschakeld, zich pas tijdens het opstarten openbaart en nergens anders.

Per release: planning van de distributie-upgrade

Ubuntu LTS-releases bieden vijf jaar standaardondersteuning en tussenliggende releases negen maanden. Uw keuze bepaalt daarmee de werklast voor upgrades voor de komende jaren. Deze afweging wordt besproken in LTS versus interim-releases op een server.

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

do-release-upgrade leest dat bestand en Prompt=lts beperkt dit tot overgangen van LTS naar LTS. Het pad van LTS naar LTS wordt doorgaans pas geopend bij de eerste point-release van de nieuwe versie in plaats van op de dag van de release zelf. Controleer daarom wat uw machine aanbiedt in plaats van te plannen op basis van een datum die u had aangenomen. De werking van de overstap staat beschreven in upgraden van Ubuntu 24.04 naar 26.04.

Houd een marge van drie maanden aan. Maak een snapshot waarvan u het herstel heeft getest, inventariseer uw externe apt-repositories (de upgrade schakelt deze uit en voor elke repository is een nieuw doel voor de nieuwe release vereist) en bepaal uw rollback-strategie voordat u begint. Sinds augustus 2026 heeft Ubuntu 24.04 LTS standaardondersteuning tot april 2029; dit is dus een kwestie van planning en geen noodgeval.

Wat te automatiseren en wat handmatig te houden

Automatiseer de beslissingen die u al heeft genomen: beveiligingsupdates, logrotatie, certificaatvernieuwing en back-uptaken. Automatiseer ook de alarmering, want een controle die afhankelijk is van uw geheugen, is een controle die om 02:00 uur niet zal plaatsvinden. Een externe monitor, zoals self-hosted statusmonitoring met Uptime Kuma, vangt het enige op wat geen enkel script op de server zelf kan rapporteren: het onbereikbaar zijn van de server.

Houd twee zaken handmatig: de hersteltest en de accountaudit. Bij beide moet een persoon beoordelen of het resultaat correct is. Als u liever de machinestatus in een browser leest dan in een terminal, vergelijkt Cockpit versus Webmin voor serverbeheer de twee gebruikelijke webconsoles.

De automatisering heeft vervolgens zelf een controle nodig. Daarom is het eerste wekelijkse punt op deze lijst het verifiëren van de updater. Automatisering die geruisloos faalt is slechter dan geen automatisering, omdat het zowel het falen als de gewoonte om te controleren tegelijkertijd wegneemt.

De volledige checklist op één plek

# 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

Hoe vaak moet ik onderhoud uitvoeren aan een Linux-server?

Wekelijks voor alles wat uit zichzelf verandert: de status van updates, de beschikbare ruimte op schijven en inodes, mislukte units en of de back-upopdracht is voltooid. Maandelijks voor langzame achteruitgang: een hersteltest, het verlopen van certificaten, de audit van accounts en SSH-keys, oude kernels en logboekgroei. Eén keer per distributierelease voor de versie-upgrade en de herstart naar de huidige kernel. De wekelijkse controle kost enkele minuten op een gezonde machine; dat is precies de reden om dit wekelijks te doen in plaats van pas wanneer er problemen zichtbaar zijn.

Waarom een hersteltest uitvoeren als de back-upopdracht succes meldt?

Omdat de opdracht rapporteert over zijn eigen exit-status, en die status kan 'true' zijn terwijl het archief onbruikbaar is. Een dump die via een pipe naar een compressor wordt gestuurd zonder set -o pipefail, geeft de status van de compressor terug. Een mislukte dump die alleen een foutmelding produceerde, eindigt dus met status nul en schrijft een klein bestand. Voer een herstel uit naar een andere machine, open de data en controleer de inhoud. De hersteltest meet ook de tijd, en die duur is uw werkelijke hersteltijd.

Moet ik na elke kernel-update herstarten?

U moet herstarten voordat de nieuwe kernel de actieve kernel is. Op Debian en Ubuntu geeft de aanwezigheid van /var/run/reboot-required aan dat een pakket hierom heeft gevraagd, en /var/run/reboot-required.pkgs vermeldt welke. Bij de RHEL-familie bestaat dat bestand niet, en needs-restarting -r uit dnf-utils beantwoordt dezelfde vraag. Stel een automatisch herstartvenster in via /etc/apt/apt.conf.d/50unattended-upgrades in plaats van dit oneindig uit te stellen, omdat een machine die een jaar niet is herstart, zowel een ongetest opstartpad als een verouderde kernel heeft.

Welke van deze controles kan ik veilig automatiseren?

Automatiseer de acties waarvoor de beslissing al is genomen: beveiligingsupdates, logrotatie, certificaatvernieuwing en geplande back-ups. Automatiseer ook de notificatie, zodat een mislukte unit of een volle schijf u bereikt zonder dat een mens een commando hoeft uit te voeren. Houd de hersteltest en de key-audit handmatig, omdat daarvoor een persoon nodig is die beoordeelt of het resultaat correct is. Voeg vervolgens één controle toe op de automatisering zelf, aangezien een stille fout in een updater er precies zo uitziet als een systeem dat naar behoren werkt.