Cron vs systemd timers pentru backup-uri: care mai pornește după un reboot la ora 3 dimineața?

Dacă backupul tău trebuie să ruleze în continuare după ce serverul a fost oprit la 3:00 AM, cron simplu este de obicei alegerea greșită. Un systemd timer cu OnCalendar= și Persistent=true este mai sigur, pentru că poate recupera o execuție ratată la următoarea pornire a hostului. Cron standard rămâne în regulă pentru housekeeping simplu, fără stare, pe mașini care sunt aproape mereu pornite. Pentru joburi reale de backup, mai ales pe VPS-uri care se restartează pentru updateuri de kernel sau mentenanță, systemd timers sunt de obicei alegerea mai curată și mai fiabilă.

Regula scurtă de decizie

• Folosește cron când jobul este simplu, serverul este practic mereu pornit, pierderea unei singure rulări este acceptabilă și vrei cât mai puține componente.
• Folosește un systemd timer când jobul contează, mașina poate fi repornită sau oprită peste noapte, vrei vizibilitate mai bună prin systemctl și journalctl, sau ai nevoie de control mai curat asupra execuției.
• Pentru joburi de backup, alegerea implicită ar trebui să fie systemd timers, dacă nu ai un motiv clar să nu faci asta.

Asta este răspunsul practic. Restul ține de evitarea capcanelor.

Ce se întâmplă, de fapt, când serverul este oprit la 3 dimineața

Cron simplu verifică programările minut cu minut cât timp daemonul cron rulează. Dacă hostul este oprit la ora programată, acea execuție este pierdută. Cron, prin el însuși, nu o reia când mașina revine online. Asta este partea pe care multe ghiduri o evită. Spun că cron este matur și testat, ceea ce este adevărat, dar omit discret semantica legată de downtime.

Anacron există tocmai pentru a atenua problema, în cazul joburilor zilnice, săptămânale sau lunare. Pe multe sisteme Linux, așa sunt tratate fluxurile clasice din /etc/cron.daily, /etc/cron.weekly și /etc/cron.monthly. Asta nu înseamnă însă că fiecare intrare din crontab devine automat persistentă. Dacă backupul tău stă într-un crontab de utilizator sau într-o regulă personalizată din /etc/cron.d/backup, trebuie să știi exact ce componentă este responsabilă pentru comportamentul de catch-up.

Systemd timers sunt mai expliciți. Dacă programezi jobul cu OnCalendar=*-*-* 03:00:00 și setezi Persistent=true, systemd salvează pe disc ultimul moment de declanșare și pornește imediat serviciul după boot dacă cel puțin o execuție programată a fost ratată cât timp timerul a fost inactiv. Exact asta este funcția care contează pentru administratorii care se ocupă de backupuri.

De ce contează mai mult la backupuri decât la joburi de curățare

Un cleanup ratat de loguri este enervant. O fereastră de backup ratată poate transforma un incident recuperabil într-o pierdere de date. Din experiența noastră cu sisteme Linux în producție, aici încetează discuția teoretică despre cron versus timer.

Ia un VPS mic care se restartează la 02:57 după un patch de kernel. Dacă backupul trebuie să ruleze la 03:00, cron simplu poate rata execuția complet, în funcție de cât de repede revine hostul și dacă momentul exact al minutului programat a trecut deja când daemonul este din nou activ. Un systemd timer persistent va recupera acea execuție ratată după boot. Asta este toată ideea.

La backupuri mari, problema devine și mai serioasă. Un stack WordPress care face dump la MariaDB, parcurge un arbore mare din wp-content/uploads și trimite date off-site poate fi deja cel mai agresiv job de I/O de pe un server Linux mic. Dacă jobul este suficient de important încât să îți pese de el, este suficient de important încât să fie programat cu ceva care are un comportament clar pentru rulările ratate.

Când cron este încă suficient de bun

Cron nu este depășit. Este încă alegerea corectă în câteva cazuri foarte comune.

• Taskul este mic și idempotent, de exemplu ștergerea unui director temporar sau rotația unui cache de aplicație care poate aștepta până mâine fără consecințe reale.
• Mașina este, în practică, mereu pornită, de exemplu un VM stabil cu rebooturi rare și fără opriri nocturne.
• Lucrezi într-un mediu vechi în care cron este deja standardul operațional acceptat, iar echipa știe exact cum se comportă.
• Jobul este deja protejat împotriva suprapunerilor și a erorilor, iar impactul de business al unei rulări ratate este mic.

Dacă asta este realitatea ta, cron rămâne perfect utilizabil. Greșeala este să pretinzi că un job de backup are același profil de risc ca ștergerea unor fișiere din /tmp.

Când un systemd timer este alegerea mai sigură

Folosește un timer când jobul are greutate operațională reală. Aici intră backupurile, exporturile de snapshot, sync-urile off-site, mentenanța certificatelor sau verificările de integritate.

• Vrei recuperare după reboot cu Persistent=true.
• Vrei ca schedulerul și jobul să fie definite explicit în unit files din /etc/systemd/system/.
• Vrei inspectare curată cu systemctl list-timers --all, systemctl status și journalctl -u.
• Vrei condiții și dependențe de execuție mai puțin fragile decât shell glue într-o linie de crontab.
• Vrei ca modelul de servicii să reducă riscul de a porni accidental a doua instanță cât timp cea anterioară încă rulează.

Asta este unul dintre cazurile în care suportul administrat chiar economisește timp. Dacă vrei ca totul să fie construit și validat pe hosturi de producție, serviciul ServerSpan de administrare Linux se ocupă de migrarea timerelor, programarea backupurilor și testarea după reboot, fără să transforme totul într-un joc de noroc la 2 noaptea.

Problema suprapunerii care rupe mai multe backupuri decât schedulerul în sine

Iată partea neplăcută: de multe ori schedulerul nu este punctul real de eșec. Problema reală este suprapunerea.

Un backup care pornește la 03:00 și încă rulează la 03:00 în ziua următoare îți spune deja că ceva este grav greșit. Dar suprapunerile mai scurte sunt și ele frecvente. Gândește-te la un job de backup care, în mod normal, se termină în 12 minute, apoi într-o noapte durează 85 de minute din cauza unei ferestre lente către object storage. Dacă cron pornește din nou înainte ca execuția anterioară să se termine, poți obține dumpuri duplicate, repository-uri blocate, stare temporară coruptă sau presiune pe I/O suficientă cât să îngenuncheze serverul.

Systemd ajută aici, fiindcă dacă service unit-ul este încă activ atunci când timerul ajunge la următoarea declanșare, systemd nu pornește o a doua instanță a aceluiași serviciu. Acesta este un comportament implicit mai bun decât o linie naivă de crontab. Totuși, nu deveni comod. Cel mai sigur model rămâne folosirea unui lock.

Pentru joburi shell, flock este cea mai simplă soluție. Folosește-l în cron. Folosește-l în ExecStart=. Folosește-l oriunde există riscul ca același backup să fie declanșat de două ori din greșeală.

Un exemplu de cron acceptabil pentru un backup simplu

Dacă insiști să rămâi pe cron, nu programa scriptul brut direct. Înfășoară-l într-un lock și trimite ieșirea într-un loc pe care chiar îl verifici.

0 3 * * * /usr/bin/flock -n /run/lock/nightly-backup.lock /usr/local/sbin/backup-nightly.sh >> /var/log/backup-nightly.log 2>&1

Asta este minimul rezonabil. Nu recuperează o execuție ratată de la 3:00 AM după downtime. Doar împiedică lansarea a două copii suprapuse dacă jobul anterior încă rulează. Pentru unele medii, este suficient. Pentru backupuri importante, de obicei nu este.

Un exemplu de systemd timer mai sigur pentru backupuri reale

Creează mai întâi un fișier de serviciu. Păstrează logica de backup în script. Păstrează programarea în timer. Păstrează prevenirea suprapunerii în execuția unit-ului.

[Unit]
Description=Nightly backup job
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/bin/flock -n /run/lock/nightly-backup.lock /usr/local/sbin/backup-nightly.sh
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Salvează acest fișier ca /etc/systemd/system/backup-nightly.service.

[Unit]
Description=Run nightly backup at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=5m
AccuracySec=1m

[Install]
WantedBy=timers.target

Salvează acest fișier ca /etc/systemd/system/backup-nightly.timer.

systemctl daemon-reload
systemctl enable --now backup-nightly.timer
systemctl list-timers --all | grep backup-nightly
systemctl status backup-nightly.timer
journalctl -u backup-nightly.service -n 100 --no-pager

Asta îți oferă o programare zilnică la 3:00 AM, recuperarea unei execuții ratate după downtime, un lock pentru a preveni suprapunerea și un flux operațional clar pentru inspecție. Din motivul ăsta, systemd timers câștigă pentru backupuri.

Capcana în care cad oamenii când încearcă să copieze logica din cron în timers

Nu confunda OnBootSec= cu o programare zilnică persistentă.

OnBootSec=3h înseamnă trei ore după boot. Nu înseamnă „rulează zilnic la 3:00 AM și recuperează dacă ai ratat”. Distincția asta contează. Dacă backupul tău trebuie să ruleze la o oră fixă din zi, folosește OnCalendar=. Apoi adaugă Persistent=true dacă recuperarea rulărilor ratate contează pentru tine.

O altă capcană este setarea RemainAfterExit=yes pe un serviciu oneshot repetitiv. Asta poate lăsa serviciul într-o stare activă care împiedică declanșările viitoare să se comporte cum te aștepți. Pentru timers repetitive de backup, păstrează serviciul oneshot simplu și lasă-l să iasă curat.

Ce nu face pentru tine nici cron, nici un timer persistent

Niciuna dintre aceste unelte nu este un job queue real.

Dacă hostul este oprit timp de trei zile, un timer persistent nu reia de obicei trei backupuri zilnice ratate, unul după altul. Recuperează o singură dată, pentru că cel puțin o execuție programată a fost ratată. Pentru fluxurile de backup, de regulă este exact ce vrei, fiindcă obiectivul este „reia protecția cât mai repede”, nu „reproduce fiecare rulare istorică ratată”. Dacă chiar ai nevoie ca fiecare interval pierdut să fie procesat separat, ai nevoie de logică de aplicație cu stare, nu doar de un scheduler.

Cum migrezi un job de backup din cron într-un timer fără să faci haos

• Inspectează intrarea actuală din cron și scriptul pe care îl cheamă. Verifică ipotezele ascunse despre PATH, shell, directorul de lucru și redirecționarea outputului.
• Rulează backupul manual înainte de orice. Dacă scriptul este fragil când îl pornești manual, schimbarea schedulerului nu îl va salva.
• Adaugă un lock dacă scriptul nu are deja unul.
• Creează fișierul .service și testează-l cu systemctl start backup-nightly.service.
• Creează fișierul .timer, dar nu îl activa până când testul serviciului nu este curat.
• Dezactivează vechea intrare din cron înainte să activezi timerul. Nu le lăsa pe ambele active „ca măsură de siguranță”. Așa apar backupurile duplicate.
• Fă un reboot controlat dacă jobul trebuie să supraviețuiască restarturilor de mentenanță. Apoi verifică systemctl list-timers --all și inspectează journalctl -u backup-nightly.service.

Dacă tot îți întărești strategia de backup, citește și ghidul nostru despre strategiile de backup pentru VPS. Dacă standardizezi în același timp și alte joburi de mentenanță, ghidul nostru despre actualizările automate pentru servere Linux acoperă aceeași disciplină operațională din perspectiva patchingului.

Recomandarea ServerSpan

Pentru backupuri, folosește systemd timers în mod implicit. Folosește cron doar când jobul este banal, hostul este mereu pornit, iar pierderea unei rulări nu reprezintă o problemă reală.

Asta este varianta directă. Cron este mai simplu. Systemd timers sunt mai sigure pentru fiabilitatea backupurilor. Dacă jobul tău de backup are orice valoare reală de recuperare, semantica pentru rulări ratate justifică singură trecerea. Adaugă un lock indiferent de alegere. Ține scriptul separat de scheduler. Testează după reboot. Apoi încetează să te prefaci că un backup nocturn este „setezi și uiți”. Nu este.

Dacă vrei ca totul să fie proiectat, migrat și testat pe un host Linux de producție, serviciul ServerSpan de administrare Linux administrată este handofful corect. Dacă muți workloadul pe o mașină unde controlezi programarea, stocarea și accesul root, un VPS Linux îți oferă spațiul necesar ca să faci lucrurile cum trebuie.