Loyiha: Backup’ni avtomatlashtirish

Bash scripting modulida katalogni arxivlaydigan, arxiv butunligini tekshiradigan va eski nusxalarni tozalaydigan backup.sh skripti yozilgan edi. O'sha paytda skript faqat qo'lda ishga tushirilardi. O'shandan beri bu modulda cron (cron asoslari, crontab va tizim cron’i, cron muhiti va log'lari) va systemd timer ko'rib chiqildi. Endi ularni birlashtirish vaqti keldi: backup skriptini inson ishtirokisiz, jadval bo'yicha ishlaydigan, natijasini tekshirish mumkin bo'lgan va nusxasi ikkinchi joyga ham yetib boradigan to'liq avtomatlashtirilgan jarayonga aylantirish.

Maqsad va yakuniy natija

Bu loyiha oxirida quyidagilar tayyor bo'ladi:

cron muhitida to'g'ri ishlashi uchun absolyut yo'llardan foydalanadigan qilib moslashtirilgan backup.sh;
cron orqali o'rnatilgan, belgilangan vaqtda ishlaydigan va chiqishi faylga yo'naltirilgan kunlik backup vazifasi;
ikki yondashuvni yonma-yon taqqoslash uchun xuddi shu vazifaning systemd timer sifatida ham sozlangani;
backup arxivining qo'shimcha ravishda rsync bilan masofaviy serverga nusxalanishi;
rejalashtirilgan ishga tushirish muvaffaqiyatsiz tugaganini qanday bilish va uni qanday tekshirishning aniq usuli.

Boshlang'ich holat

Oldingi moduldagi lab’dagi kabi ish alohida test kataloglarida olib boriladi. Bu haqiqiy tizim kataloglarini xavfdan uzoq tutadi:

mkdir -p ~/lab/backup-automation/{data,backups}
cd ~/lab/backup-automation
printf 'client list\n' > data/clients.txt
mkdir -p data/invoices
printf 'invoice-2026-07\n' > data/invoices/inv-001.txt

Loyiha: Backup skripti dagi tayyor skriptni shu katalogga backup.sh nomi bilan nusxalang va uni bajariladigan qiling:

chmod +x backup.sh

Talablar

ishlaydigan backup.sh skripti (oldingi loyihadan) yoki uning nusxasi;
ishlab turgan cron servisi (systemctl status cron);
zamonaviy, systemd’ga asoslangan Ubuntu Server LTS tizimi (timer qadami uchun);
ixtiyoriy: rsync qadamini sinab ko'rish uchun ikkinchi mashina yoki SSH orqali ulanish mumkin bo'lgan masofaviy manzil. U bo'lmasa, bu qadamni ikkinchi mahalliy katalogga nusxalash orqali taqlid qilish mumkin.

Xavfsizlik va snapshot haqida eslatma

Bu loyihaning ikki qismi buzuvchi xususiyatga ega: oldingi loyihadan meros qolgan va eski arxivlarni o'chiradigan cleanup_old_backups, hamda bu yerda qo'shiladigan masofaviy rsync sinxronizatsiyasi. Ikkinchisi --delete bilan ishga tushirilsa, manbada endi mavjud bo'lmagan ortiqcha fayllarni qabul qiluvchi tomonda o'chiradi. Quyidagi ikkala qoida ham amal qiladi:

hamma narsani avval lab kataloglarida sinab ko'ring, hech qachon haqiqiy backup’lar yoki production ma’lumotlarida emas;
har qanday rsync --delete ning birinchi ishga tushirilishi har doim --dry-run bo'ladi;
biror narsani cron vazifasi yoki timer sifatida o'rnatishdan oldin skriptni kamida bir marta muvaffaqiyatli tugaguncha qo'lda ishga tushiring.

Bosqichma-bosqich vazifalar

1-qadam: skriptni cron muhitiga moslashtirish

cron muhiti va log'lari maqolasida ko'rib chiqilganidek, cron’ning PATH i terminalnikidan qisqaroq, ishchi katalogi esa boshqacha. Skript ichidagi tar va find kabi buyruqlar odatda muammo tug'dirmaydi, chunki ular standart joylarda (/usr/bin, /bin) joylashgan. Lekin skriptning o'zi qanday chaqirilishi va unga uzatiladigan argumentlar faqat absolyut yo'llardan foydalanishi kerak:

readlink -f backup.sh

/home/<username>/lab/backup-automation/backup.sh

Tekshirish — skriptni to'liq absolyut yo'llar bilan qo'lda ishga tushiring:

/home/<username>/lab/backup-automation/backup.sh \
  /home/<username>/lab/backup-automation/data \
  /home/<username>/lab/backup-automation/backups

Kutilgan natija:

[2026-07-26 10:02:14] Backup successful: /home/<username>/lab/backup-automation/backups/data-20260726-100214.tar.gz
[2026-07-26 10:02:14] Verification OK: .../data-20260726-100214.tar.gz intact
[2026-07-26 10:02:14] Backup process complete

2-qadam: cron vazifasini o'rnatish

crontab -e

0 2 * * * /home/<username>/lab/backup-automation/backup.sh /home/<username>/lab/backup-automation/data /home/<username>/lab/backup-automation/backups 7 >> /home/<username>/lab/backup-automation/cron-backup.log 2>&1

Bu qatorda uchta narsa muhim:

har bir yo'l absolyut — skriptning o'zi ham, uning argumentlari ham, log fayl ham;
>> ... 2>&1 skriptning o'z log() funksiyasi ustidan qo'shimcha himoya qatlamini qo'shadi va kutilmagan xatolarni ham (masalan, tar ning o'zi ishga tusha olmaganini) ushlaydi;
MAILTO ataylab ishlatilmagan — chiqish email’ga emas, faylga yuboriladi. Bu production’da ishonchliroq tanlov (cron muhiti va log'lari maqolasida ko'rib chiqilganidek).

Tekshirish:

crontab -l

0 2 * * * /home/<username>/lab/backup-automation/backup.sh ...

Natijani darhol ko'rish uchun soat 2:00 gacha kutish o'rniga jadvalni vaqtincha bir necha daqiqa keyinga o'zgartiring:

crontab -e

*/2 * * * * /home/<username>/lab/backup-automation/backup.sh /home/<username>/lab/backup-automation/data /home/<username>/lab/backup-automation/backups 7 >> /home/<username>/lab/backup-automation/cron-backup.log 2>&1

Ikki-uch daqiqadan keyin:

tail -n 5 ~/lab/backup-automation/cron-backup.log
journalctl -u cron.service --since "5 minutes ago" | grep backup.sh

Kutilgan natija: log faylda yangi backup yozuvlari paydo bo'ladi, journalctl da esa CMD (backup.sh ...) chaqiruvi ko'rinadi. Tasdiqlangandan keyin jadvalni yana 0 2 * * * ga qaytaring.

3-qadam: systemd timer bilan taqqoslash

systemd timer’lar maqolasidagi shablonga amal qilib, xuddi shu vazifa timer sifatida sozlanadi:

sudo nano /etc/systemd/system/lab-backup.service

[Unit]
Description=Lab backup automation

[Service]
Type=oneshot
User=<username>
ExecStart=/home/<username>/lab/backup-automation/backup.sh /home/<username>/lab/backup-automation/data /home/<username>/lab/backup-automation/backups 7

Bu yerda User= muhim: usiz systemd unit’lari standart holatda root nomidan ishlaydi. Bu esa arxiv fayllarini ularga egalik qilishi kerak bo'lgan akkaunt o'rniga root ga tegishli qilib qo'yadi.

sudo nano /etc/systemd/system/lab-backup.timer

[Unit]
Description=Daily schedule for lab-backup.service

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now lab-backup.timer

Tekshirish:

systemctl list-timers lab-backup.timer
sudo systemctl start lab-backup.service
journalctl -u lab-backup.service --since today

Kutilgan natija: list-timers keyingi rejalashtirilgan ishga tushirishni ko'rsatadi, qo'lda ishga tushirilgan servis darhol yangi backup yaratadi, uning to'liq chiqishi (skriptdagi log() funksiyasining echo qatorlari) esa to'g'ridan-to'g'ri journalctl da ko'rinadi. cron versiyasidan farqli o'laroq, log'ni alohida yo'naltirish kerak emas.

4-qadam: arxivni masofaviy serverga nusxalash

Faqat bitta diskda turgan backup o'sha disk yoki butun server ishdan chiqsa, hech qanday himoya bermaydi. Arxiv scp va rsync maqolasida ko'rib chiqilgan rsync yordamida boshqa serverga (yoki sinov uchun boshqa mahalliy katalogga) nusxalanadi:

mkdir -p ~/lab/backup-automation/remote-simulation

Har doim avval --dry-run bilan tekshiring:

rsync -avz --dry-run ~/lab/backup-automation/backups/ ~/lab/backup-automation/remote-simulation/

sending incremental file list
data-20260726-100214.tar.gz
data-20260726-100214.tar.gz.log

sent 234 bytes  received 20 bytes  508.00 bytes/sec
total size is 457  speedup is 1.80 (DRY RUN)

Agar natija to'g'ri ko'rinsa, --dry-run ni olib tashlang va haqiqatan nusxalang:

rsync -avz ~/lab/backup-automation/backups/ ~/lab/backup-automation/remote-simulation/

Haqiqiy masofaviy serverga nusxalashda manzil quyidagicha ko'rinadi (avval SSH kalit autentifikatsiyasini sozlash kerak, SSH kalit autentifikatsiyasi maqolasida ko'rib chiqilganidek):

rsync -avz ~/lab/backup-automation/backups/ [email protected]:/srv/backups/myapp/

Bu qadamni backup.sh ga qo'shimcha funksiya sifatida qo'shish ham mumkin edi. Lekin uni skriptning asosiy arxivlash mantiqidan tashqarida, alohida va ixtiyoriy qadam sifatida saqlagan ma’qul: agar masofaviy server vaqtincha mavjud bo'lmasa, mahalliy backup baribir yakunlanishi kerak.

5-qadam: backup tiklanishini isbotlash va muvaffaqiyatsizlik haqida xabar olish

Haqiqiy backup tizimini shunchaki .tar.gz fayllar ishlab chiqaradigan skriptdan ikkita operatsion haqiqat ajratib turadi.

Backup faqat tiklash bilan isbotlanadi. Oldingi skriptdan meros qolgan tar butunlik tekshiruvi arxiv buzilmaganini tasdiqlaydi, lekin uning ichidagilari haqiqatan foydalanishga yaroqli ekanini tasdiqlamaydi. Vaqti-vaqti bilan arxivni vaqtinchalik katalogga tiklang va uni manba bilan diff orqali solishtiring:

mkdir -p ~/lab/backup-automation/restore-test
tar -xzf ~/lab/backup-automation/backups/data-20260726-100214.tar.gz \
    -C ~/lab/backup-automation/restore-test
diff -r ~/lab/backup-automation/data ~/lab/backup-automation/restore-test/data

Bo'sh diff chiqishi tiklangan katalog daraxti asl nusxaga aynan mos kelishini tasdiqlaydi. "Bir yil davomida backup’lar ishlab turdi, lekin ularning birortasi ham haqiqatan tiklanmadi" — bu karyerani belgilab beradigan real muvaffaqiyatsizlik. Sinab ko'rilmagan backup — bu shunchaki umid.

Jimlik muvaffaqiyat degani emas. cron log fayli ham, journalctl ham passiv: soat 02:00 da ularni hech kim o'qimaydi, jimgina muvaffaqiyatsiz tugagan vazifa esa tiklash haqiqatan kerak bo'lgan kungacha muvaffaqiyatli tugagan vazifadan farq qilmaydi. Production’da vazifa muvaffaqiyatsizlik haqida faol signal berishi kerak. Buning uchun o'rab turuvchi (wrapper) skript asosiy skriptning exit kodini tekshirib, noldan farqli bo'lsa, ogohlantirish yuborsin (kuzatiladigan manzilga email, chat kanaliga webhook yoki monitoring tizimiga hodisa). Mustahkamroq variant — dead-man’s switch: vazifa tashqi monitorga faqat muvaffaqiyatli tugaganda signal (ping) yuboradi, kutilgan signal o'z vaqtida kelmasa, monitor ogohlantirish beradi. Bu vazifa umuman ishga tushmagan qiyinroq holatni ham (to'xtab qolgan cron daemon, o'chirib qo'yilgan timer) ushlaydi. "Xato bo'lganda baqir" yondashuvi buni hech qachon aniqlay olmaydi, chunki umuman ishga tushmagan vazifa hech qachon baqirmaydi.

Troubleshooting bo'yicha eslatmalar

cron vazifasi jim, log fayl ham bo'sh. Vazifa umuman ishga tushayotganini journalctl -u cron.service --since today | grep backup.sh bilan tekshiring. Agar u yerda ham yozuv bo'lmasa, muammo crontab qatorining o'zida (qarang: crontab va tizim cron’i).
Log faylda "tar: command not found" yoki shunga o'xshash xabar chiqadi. cron’ning PATH i qisqaroq (qarang: cron muhiti va log'lari). Skriptdagi har bir tashqi buyruq uchun absolyut yo'ldan foydalaning yoki crontab boshida PATH ni kengaytiring.
systemd timer versiyasi root ga tegishli arxivlar yaratadi. lab-backup.service da User= qatori yo'q yoki noto'g'ri. Uni tuzating, keyin sudo systemctl daemon-reload ni ishga tushiring va servisni qayta ishga tushiring.
rsync masofaviy serverga ulana olmayapti. Avval oddiy ssh [email protected] ulanishi o'zi alohida ishlashini tasdiqlang. Muammo odatda rsync ning o'zida emas, SSH kalitida yoki known_hosts da bo'ladi.

Orqaga qaytarish va tozalash

Sinovdan keyin cron va systemd timer vazifalarini olib tashlang, aks holda ular test kataloglariga qarshi cheksiz ishlashda davom etadi:

crontab -e

Oldin qo'shilgan qatorni o'chiring va saqlang, keyin:

sudo systemctl disable --now lab-backup.timer
sudo rm /etc/systemd/system/lab-backup.service /etc/systemd/system/lab-backup.timer
sudo systemctl daemon-reload

Test kataloglarini butunlay o'chiring:

rm -rf ~/lab/backup-automation

Yakuniy baholash mezonlari

Loyiha quyidagi holatda tugallangan hisoblanadi:

backup.sh cron orqali chaqirilganda faqat absolyut yo'llardan foydalanib, xatosiz ishlaydi;
cron vazifasining natijasi ham log faylda, ham journalctl -u cron.service da tasdiqlangan;
xuddi shu vazifa systemd timer sifatida ham ishlaydi va uning natijasi alohida log yo'naltirishsiz journalctl -u lab-backup.service orqali ko'rinadi;
arxiv boshqa katalog yoki serverga muvaffaqiyatli nusxalanishidan oldin rsync --dry-run bilan tekshirilgan;
kamida bitta arxiv sinov tariqasida tiklangan va foydalanishga yaroqli ekanini isbotlash uchun manba bilan diff orqali solishtirilgan;
sinovdan keyin barcha vaqtinchalik cron va systemd unit’lari olib tashlangan.

Xulosa

Bu loyiha modulda ko'rib chiqilgan hamma narsani — cron sintaksisi, foydalanuvchi va tizim crontab’lari, cron’ning o'ziga xos muhiti va systemd timer muqobili — bitta amaliy avtomatlashtirish zanjiriga birlashtirdi: skript endi inson ishtirokisiz, jadval bo'yicha ishlaydi, uning natijasini tekshirish mumkin, arxiv esa boshqa joyga ham nusxalanadi. Keyingi modul Linux xavfsizligiga o'tadi — eng kam imtiyoz tamoyili (least privilege), sudo sozlamalari va parol siyosatlari.