Linux server maintenance checklist: साप्ताहिक व मासिक

Linux server maintenance म्हणजे प्रत्यक्षात काय

Linux server maintenance म्हणजे ठरावीक वेळापत्रकानुसार केली जाणारी तपासण्यांची छोटी यादी आहे. ती कधीही न संपणारी project नाही. दर आठवड्याला updates install झाले आहेत का, disk वर पुरेशी जागा आहे का, कोणतीही service बंद पडलेली नाही ना आणि backup job पूर्ण झाली का हे तपासा. दर महिन्याला restore ची चाचणी घ्या, certificate ची expiry तपासा, accounts आणि keys चे audit करा आणि जुने kernels व logs काढून टाका. प्रत्येक distribution release वेळी version upgrade चे नियोजन करा आणि सतत पुढे ढकलत असलेला reboot करा.

Server तयार करणे हे वेगळे काम आहे. नवीन VPS वरील पहिली दहा मिनिटे या भागात त्याची माहिती आहे. हे पृष्ठ त्यानंतरच्या वर्षासाठी आहे. खालील प्रत्येक मुद्द्यात तो कोणता failure टाळतो हे स्पष्ट केले आहे. कारण परिणाम माहीत नसलेली checklist लोक हळूहळू वापरणे बंद करतात.

येथील commands उदाहरणांसाठी आहेत. त्या चालवण्यापूर्वी त्यांचा अर्थ समजून घ्या. त्यांचे output तुमच्या server वरील output शी तुलना करा. Free space किंवा process count साठी योग्य value ही server कशासाठी वापरला जातो यावर अवलंबून असते. Distributions नुसार एखादी तपासणी वेगळी असल्यास मजकुरात ते स्पष्ट केले आहे. उदाहरणांमध्ये Debian आणि Ubuntu सोबत apt वापरले आहे. RHEL family मध्ये tooling dnf आहे आणि अनेक paths वेगळे आहेत.

तुम्ही नियमितपणे पाळू शकाल असे Linux सर्व्हर देखभाल वेळापत्रक कसे ठरवावे

साप्ताहिक तपासण्यांमध्ये तुमच्याशिवाय बदलणाऱ्या गोष्टींचा समावेश होतो: packages, disk usage, service state आणि scheduled jobs. या गोष्टी आपोआप बदलतात. त्यामुळे त्यांची तपासणी न करता ठेवण्याची कमाल मुदत साधारणपणे एक आठवडा असावी.

मासिक तपासण्यांमध्ये हळूहळू निर्माण होणाऱ्या समस्या येतात: मुदत संपण्याच्या जवळ आलेली certificates, कोणीही काढून न टाकलेली accounts, /boot मध्ये साचत जाणारे kernels आणि rotation rule शी जुळणे थांबलेली, त्यामुळे वाढत जाणारी log files. यांपैकी कोणतीही समस्या उद्या उद्भवेलच असे नाही. पण शेवटी त्या सर्व समस्या निर्माण करतात.

Release checks या calendar नुसार केल्या जातात. Distribution release ही बाह्य अंतिम मुदत असलेली एकमेव देखभाल बाब आहे. कारण तुमची सध्याची version समर्थित राहणे थांबते, तुम्ही तयार असलात किंवा नसलात तरी.

ही तपासणी ठरावीक वेळेत करा: साप्ताहिक तपासणीसाठी सोमवार सकाळ आणि मासिक तपासणीसाठी महिन्याचा पहिला दिवस ठरवा. "वेळ मिळेल तेव्हा" केली जाणारी checklist run ही checklist नसते. काही machines पेक्षा जास्त server असल्यास या तपासण्या हाताने करण्याऐवजी एकाच ठिकाणाहून चालवा. याच विषयावर एकाच ठिकाणाहून अनेक Linux servers व्यवस्थापित करणे माहिती दिली आहे.

साप्ताहिक: अद्यतने प्रत्यक्षात स्थापित झाली का?

unattended-upgrades सक्षम करणे आणि ते चालले हे माहीत असणे या वेगळ्या गोष्टी आहेत. सेवा masked असू शकते, configuration तुम्ही वापरत नसलेल्या origin पर्यंत मर्यादित असू शकते आणि एक held package त्यानंतरच्या प्रत्येक run मध्ये अडथळा आणू शकतो. ते स्थापित करण्याची पद्धत Ubuntu वरील स्वयंचलित security updates मध्ये दिली आहे. साप्ताहिक job चा उद्देश म्हणजे तुम्ही स्थापित केलेल्या automation ने प्रत्यक्ष काम केले हे सिद्ध करणे.

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 हे वास्तव दर्शवणारे मोजमाप आहे, कारण ते अपेक्षित स्थितीऐवजी सध्याची स्थिती दाखवते. त्या यादीत अजूनही security updates दिसत असतील, तर automation योग्य प्रकारे काम करत नाही. त्यामुळे मशीन patched आहे असे गृहीत धरण्यापूर्वी log वाचा. apt-mark hold ने pinned केलेले package कायमचे skipped राहते आणि कोणतीही माहिती नोंदवत नाही. म्हणूनच त्याच तपासणीत apt-mark showhold देखील समाविष्ट असावे.

यामुळे टाळली जाणारी समस्या: updates automatic आहेत असा समज ठेवून, ज्ञात असुरक्षित package अनेक महिने चालू ठेवणे.

साप्ताहिक: डिस्क आणि inode साठी उपलब्ध मोकळी क्षमता

मूळ filesystem पूर्ण भरल्यास डिस्कशी असंबंधित वाटणाऱ्या गोष्टीही बिघडतात. डेटाबेस write नाकारतो, logging थांबते, package upgrade अर्धवट configuration नंतर अपयशी ठरतो आणि काही सेटअपमध्ये नवीन session उघडता येत नाही, कारण त्याच्या स्वतःच्या फाइल्स लिहिता येत नाहीत.

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

df -i हा बहुतेक लोक वगळणारा भाग आहे. Inode ही file metadata ठेवणारी निश्चित-संख्येची संरचना आहे. df -h अजूनही अनेक gigabytes मोकळी जागा दाखवत असतानाही filesystem मधील inode संपुष्टात येऊ शकतात. त्यानंतर output मध्ये जागा शिल्लक असल्याचे दिसत असले, तरी write No space left on device सह अपयशी ठरतात. पहिल्यांदा असे घडल्यास यामुळे कारण शोधण्यासाठी बराच वेळ जातो. अडकलेली mail queue किंवा कोणीही साफ न केलेली session directory यांमधील लाखो लहान फाइल्स हे याचे नेहमीचे कारण आहे.

du -xh एकाच filesystem वरच राहते. Bind mounts किंवा attached storage असलेल्या server साठी हेच अपेक्षित आहे. Docker host वर उत्तर सहसा image layers आणि dead volumes मध्ये असते. VPS वरील Docker disk usage prune करणे येथे वर्णन केल्याप्रमाणे ते साफ करता येतात.

मोकळी जागा capacity बद्दल माहिती देते. तिच्या खालील storage चे failure स्वतंत्र वेळापत्रकानुसार होते. त्यामुळे ही वेगळी तपासणी आहे. तिचे वर्णन VPS वरील disk health monitoring येथे केले आहे.

साप्ताहिक: तुम्हाला न सांगता काय बंद पडले?

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

क्रॅश झालेली आणि restart limit गाठलेली unit failed स्थितीतच राहते. ती तिथे शांतपणे पडून राहते. तिच्याबद्दल तुम्हाला ईमेलद्वारे कोणतीही सूचना मिळत नाही. list-timers हा अधिक उपयुक्त भाग आहे: प्रत्येक timer शेवटचा कधी चालला आणि पुढच्या वेळी कधी चालेल हे तो दाखवतो. त्यामुळे timer च्या स्वतःच्या interval पेक्षा जुनी LAST value असल्यास ते job अजिबात चाललेले नाही.

unit restart करण्यापूर्वी journalctl -u <unit> -n 100 --no-pager वापरून तिचा journal वाचा. restart केल्याने लक्षण नाहीसे होते. त्यानंतर तीच समस्या अधिक गैरसोयीच्या वेळी पुन्हा होईपर्यंत तपासण्याचे कारण उरत नाही.

यामुळे पुढील प्रकारचे अपयश टाळता येते: memory spike मुळे तीन आठवड्यांपासून बंद असलेला monitoring agent, queue worker किंवा backup service.

साप्ताहिक तपासणी: बॅकअप जॉब प्रत्यक्षात पूर्ण झाला का?

शेड्यूल केलेला बॅकअप आणि पूर्ण झालेला बॅकअप हे वेगळे तथ्य आहेत. यापैकी फक्त पूर्ण झालेला बॅकअप restore करता येतो. पूर्णता तपासा.

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

दोन गोष्टींची खात्री करा. शेवटचा रन zero exit status सह पूर्ण झाला आहे आणि सर्वात नवीन archive अलीकडील असून तुमच्या अपेक्षेप्रमाणे साधारण आकाराचा आहे. नेहमीच्या आकाराच्या केवळ एक-दशांश आकाराची बॅकअप फाइल अचानक दिसत असल्यास, dump अयशस्वी झाला असूनही फाइल लिहिली गेली आहे. बॅकअप अयशस्वी होण्याचा हा सर्वात धोकादायक प्रकार आहे, कारण त्यानंतरची संपूर्ण प्रक्रिया सामान्य दिसते.

तुमची script dump ला compressor कडे pipe करत असल्यास, सुरुवातीला set -o pipefail जोडा. हे नसल्यास pipeline चा exit status compressor चा असतो. Compressor यशस्वी झाला, कारण त्याने error message compress केला. त्यामुळे job दररोज रात्री success दाखवते आणि काहीही नसलेले छोटे archive लिहिते.

मासिक: बॅकअप दुसऱ्या ठिकाणी पुनर्संचयित करा

बहुतेक लोक वगळतात तो हा टप्पा आहे. उर्वरित यादी उपयुक्त ठरली की नाही हे याच्यावर अवलंबून असते.

लाइव्ह डेटावर कधीही पुनर्संचयित करू नका. त्याऐवजी वेगळ्या मशीनवर किंवा नवीन कंटेनरमध्ये पुनर्संचयित करा. त्यानंतर पुनर्संचयित केलेला डेटा उघडून तो प्रत्यक्षात उपलब्ध आहे का ते तपासा. एखाद्या टेबलमधील rows मोजा. एखादा document उघडा. पुनर्संचयित केलेल्या application मध्ये log in करा. Extraction पूर्ण झाले, यावरून archive वाचता येते एवढेच सिद्ध होते.

Repository tools साठी स्वतंत्र verification उपलब्ध असते: restic check --read-data-subset=5% आणि borg check --verify-data index ऐवजी साठवलेला data वाचतात. ही commands चालवा आणि त्यांना smoke test समजा; पर्याय समजू नका. Verification मुळे bytes सुरक्षित राहिल्याची खात्री होते. Restore मुळे ते bytes application ला आवश्यक असलेलेच आहेत का ते तपासले जाते.

दोन गोष्टी लोकांना कठीण अनुभवातून शिकाव्या लागतात. ज्या मशीनवर agent मध्ये key आधीपासून उपलब्ध नाही, अशा मशीनवर decryption passphrase तपासा; कारण decrypt करता न येणारा backup म्हणजे backup नाही. तसेच restore ला लागणारा वेळ मोजा. तोच तुमचा प्रत्यक्ष recovery time असतो. हा वेळ outage दरम्यान समजणे ही त्याची नेहमीची आणि सर्वात वाईट वेळ असते.

मासिक: कोणती प्रमाणपत्रे लवकर कालबाह्य होणार आहेत?

नूतनीकरणाची स्वयंचलित प्रक्रिया अनेकदा शांतपणे अपयशी ठरते. certbot timer डिस्कवरील फाइलचे नूतनीकरण करू शकतो; परंतु service पुन्हा load करणारा deploy hook चालला नसेल, तर web server memory मधून जुने प्रमाणपत्रच देत राहतो. त्यामुळे मशीनच्या बाहेरून चालू server कोणते प्रमाणपत्र देत आहे ते तपासा.

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 flag SNI (server name indication) सेट करतो. एकाच address वर एकापेक्षा अधिक sites host केले असल्यास हे आवश्यक असते. अन्यथा तुम्हाला तुमच्या site ऐवजी default certificate दिले जाते. certbot snap मधून install केले असल्यास timer चे नाव वेगळे असते. त्यामुळे गृहीत धरलेल्या unit ऐवजी शब्दावर match करा.

पूर्णपणे स्वयंचलित नूतनीकरण नसलेली प्रमाणपत्रेही लक्षात ठेवा: mail server, VPN आणि internal certificate authority यांची प्रमाणपत्रे. ही प्रमाणपत्रे अनेकदा weekend ला कालबाह्य होतात. Browsers आणि clients त्यांना warning दाखवण्याऐवजी थेट नाकारतात.

मासिक: वापरकर्ते, sudo प्रवेश आणि 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 प्रत्येक Include एकत्र केल्यानंतरची प्रभावी configuration दाखवते. प्रत्यक्षात daemon हीच configuration वापरतो. अलीकडील Ubuntu images मध्ये /etc/ssh/sshd_config.d/ येथे drop-in files दिलेल्या असतात. त्या मुख्य file मधील settings वर override करू शकतात. त्यामुळे फक्त sshd_config वाचल्यास प्रत्यक्ष configuration च्या उलट निष्कर्ष निघू शकतो. RHEL family मध्ये administrative group sudo ऐवजी wheel असतो. त्यामुळे getent line त्यानुसार बदला.

त्यानंतर authorized_keys files स्वतः वाचा. प्रवेश account नुसार नव्हे, तर key नुसार दिला जातो. त्यामुळे सहा महिन्यांपूर्वी काम पूर्ण केलेल्या contractor ने मागे ठेवलेली key अद्याप कार्यरत login असू शकते. User list मध्ये ती दिसेलच असे नाही. Keys मध्ये comment field असते. त्याचा वापर करा. ज्या key चा संबंध कोणत्याही व्यक्तीशी जोडता येत नाही ती delete करा.

Login history साठी journalctl -t sshd --since "30 days ago" | grep -i accepted unit name ऐवजी syslog identifier वर match करते. हे महत्त्वाचे आहे, कारण Ubuntu 24.04 मध्ये SSH socket द्वारे activate होते. त्यामुळे प्रत्येक connection ची नोंद connection-specific generated unit अंतर्गत केली जाते. साधे journalctl -u ssh वापरल्यास या नोंदी सापडणार नाहीत.

मासिक: जुने kernels आणि पूर्ण भरलेले /boot

/boot हे सामान्य VPS image मध्ये काहीशे megabytes चे स्वतंत्र partition असते. प्रत्येक kernel update त्यात एक image आणि एक initramfs जोडतो. ते भरल्यावर पुढील upgrade मध्येच अपयश येते आणि packages unconfigured अवस्थेत राहतात. त्यामुळे शुक्रवारी अचानक अशी स्थिती निर्माण होणे धोकादायक असते.

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

uname -r आधी नेहमी तपासा: त्यात सध्या चालू असलेल्या kernel चे नाव दिसते. तुम्ही जे काही काढाल त्यातून हा kernel सुरक्षित राहिलाच पाहिजे. Debian आणि Ubuntu मधील सामान्य परिस्थिती apt autoremove हाताळते, कारण kernels automatically installed म्हणून चिन्हांकित असतात आणि सध्याच्या kernel चे संरक्षण केले जाते. manually installed kernel किंवा /boot आधीच इतके भरलेले असेल की apt स्वतःही चालू शकत नसेल, तर त्या edge cases साठी Ubuntu वर जुने kernels काढणे हा विभाग पहा.

मासिक: log वाढ आणि systemd journal

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

logrotate --debug ही dry run आहे आणि त्यात काहीही लिहिले जात नाही, त्यामुळे ती live box वर सुरक्षित आहे. हे चालवणे उपयुक्त आहे, कारण rotation rules path नुसार लागू होतात: upgrade दरम्यान log location बदललेला application त्याच्या स्वतःच्या rule च्या कक्षेबाहेर जातो आणि ती file disk भरून जाईपर्यंत अमर्याद वाढत राहते.

systemd journal ची कमाल मर्यादा ठरवतो; मात्र ती तुम्ही निवडलेल्या संख्येऐवजी filesystem च्या एका अंशावर आधारित असते. विशिष्ट ceiling हवी असल्यास /etc/systemd/journald.conf मध्ये SystemMaxUse= सेट करा आणि systemd-journald restart करा. sudo journalctl --vacuum-time=14d त्वरित space मोकळी करते. ही policy नसून one-time action आहे, त्यामुळे ती config change सोबत लागू करा.

प्रत्येक release नंतर: तुम्ही सतत पुढे ढकलत असलेला reboot

डिस्कवर असलेले updated kernel package म्हणजे चालू असलेला kernel नाही. reboot होईपर्यंत मशीन जुना kernelच चालवते. live patching उपलब्ध असल्यास, त्यातूनही फक्त काही fixes लागू होतात.

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

ही flag file Debian आणि Ubuntu मधील package scripts वापरणारी पद्धत आहे. RHEL family systems ही file तयार करत नाहीत. तेथे समतुल्य माहिती needs-restarting -r देते आणि ती dnf-utils मधून येते. अलीकडील Ubuntu server images मध्ये default ने install केलेले needrestart kernel पेक्षा खालच्या स्तरावरील स्थिती दाखवते. डिस्कवर बदललेल्या library चे mapping अजूनही ठेवणाऱ्या processes ची ती यादी देते. त्यामुळे patched OpenSSL वापरणाऱ्या services restart होईपर्यंत त्याचा परिणाम होत नाही.

reboot टाळण्याऐवजी तो schedule करा. /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; आणि Unattended-Upgrade::Automatic-Reboot-Time "03:00"; मध्ये निर्णय तुम्ही निवडलेल्या वेळेकडे सोपवा. नियोजित reboot हाच मशीन पुन्हा सुरू होते की नाही हे तपासण्याचा एकमेव मार्ग आहे. कारण चुकीची fstab entry किंवा तुम्ही कधीही enable न केलेली service boot वेळी दिसून येते; इतर कोणत्याही वेळी नाही.

प्रति रिलीज: distribution upgrade चे नियोजन

Ubuntu LTS releases ला पाच वर्षांचा standard support मिळतो, तर interim releases ला नऊ महिन्यांचा support मिळतो. त्यामुळे ही निवड पुढील अनेक वर्षांसाठी तुमचे upgrade workload ठरवते. हा trade-off सर्व्हरवरील LTS विरुद्ध interim releases असा आहे.

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

do-release-upgrade ती file वाचते, तर Prompt=lts ती प्रक्रिया फक्त LTS-to-LTS moves पर्यंत मर्यादित ठेवते. LTS-to-LTS path सहसा नवीन version च्या release day ला उपलब्ध होत नाही. तो नवीन version च्या पहिल्या point release पासून उपलब्ध होतो. त्यामुळे तुम्ही गृहीत धरलेल्या तारखेवर नियोजन करण्याऐवजी तुमच्या machine ला कोणता पर्याय दिला जात आहे ते तपासा. या jump ची पद्धत Ubuntu 24.04 ला 26.04 वर upgrade करणे येथे दिली आहे.

तीन महिन्यांचा अतिरिक्त अवधी ठेवा. Restore करून तपासलेला snapshot घ्या. तुमच्या third-party apt repositories ची यादी तयार करा. Upgrade दरम्यान त्या disable होतात आणि प्रत्येक repository साठी नवीन release ला अनुरूप target आवश्यक असते. प्रक्रिया सुरू करण्यापूर्वी rollback कसा करायचा ते ठरवा. August 2026 पर्यंत Ubuntu 24.04 LTS ला April 2029 पर्यंत standard support आहे. त्यामुळे हे emergency नसून scheduling चे काम आहे.

काय स्वयंचलित करावे आणि काय हस्तचलित ठेवावे

तुम्ही आधीच घेतलेले निर्णय स्वयंचलित करा: सुरक्षा अद्यतने, log rotation, प्रमाणपत्रांचे renewal आणि backup jobs. Alerting देखील स्वयंचलित करा. कारण एखादी तपासणी तुमच्या लक्षात ठेवण्यावर अवलंबून असेल, तर ती पहाटे 2 वाजता होणार नाही. Uptime Kuma सह self-hosted status monitoring सारखा बाह्य monitor अशी एक बाब पकडतो, जी on-box script पैकी कोणतीही script कळवू शकत नाही: server शी संपर्क होणे अशक्य झाले आहे.

दोन गोष्टी हस्तचलित ठेवा: restore test आणि account audit. दोन्हींसाठी निकाल योग्य आहे का हे एखाद्या व्यक्तीने ठरवणे आवश्यक असते. Terminal ऐवजी browser मध्ये machine state पाहणे तुम्हाला अधिक सोयीचे वाटत असल्यास, server management साठी Cockpit विरुद्ध Webmin या दोन प्रचलित web console ची तुलना करते.

Automation ची देखील स्वतंत्र तपासणी आवश्यक असते. म्हणून या यादीतील पहिला साप्ताहिक मुद्दा updater ची पडताळणी करणे हा आहे. शांतपणे अपयशी होणारे automation नसण्यापेक्षा अधिक धोकादायक असते. कारण त्यामुळे अपयशही दिसत नाही आणि त्याच वेळी तपासणी करण्याची सवयही नष्ट होते.

संपूर्ण तपासणीसूची एकाच ठिकाणी

# 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 server maintenance किती वेळा चालवावे?

स्वतःहून बदलणाऱ्या गोष्टींसाठी हे साप्ताहिक करा: update status, disk आणि inode headroom, failed units आणि backup job पूर्ण झाले आहे का हे तपासा. हळूहळू होणाऱ्या बदलांसाठी हे मासिक करा: restore test, certificate expiry, account आणि SSH key audit, जुने kernels आणि log growth. Version upgrade आणि current kernel वर reboot करण्यासाठी प्रत्येक distribution release वेळी हे करा. व्यवस्थित चालणाऱ्या server वर साप्ताहिक तपासणीला काही मिनिटे लागतात. काहीतरी चुकीचे दिसेपर्यंत थांबण्याऐवजी ती साप्ताहिक करण्याचा हाच उद्देश आहे.

Backup job यशस्वी झाल्याचे दाखवत असेल, तरी restore test का करावा?

कारण job स्वतःच्या exit status बद्दल माहिती देते. तो status यशस्वी असला तरी archive निरुपयोगी असू शकतो. set -o pipefail शिवाय dump compressor कडे pipe केल्यास compressor चा status परत मिळतो. त्यामुळे फक्त error message तयार करणारा failed dump देखील zero exit status देतो आणि लहान file लिहितो. वेगळ्या machine वर restore करा, data उघडा आणि एखाद्या घटकाची संख्या मोजा. Restore ला लागलेला वेळही नोंदवा. हाच तुमचा वास्तविक recovery time असतो.

प्रत्येक kernel update नंतर reboot करणे आवश्यक आहे का?

नवीन kernel प्रत्यक्षात running kernel होण्यापूर्वी reboot करणे आवश्यक आहे. Debian आणि Ubuntu वर /var/run/reboot-required ही file package ने reboot ची मागणी केली आहे असे दर्शवते, तर /var/run/reboot-required.pkgs कोणत्या package ने ती मागणी केली ते दाखवते. RHEL family मध्ये ही file नसते. तेथे dnf-utils कडून मिळणारे needs-restarting -r हाच प्रश्न सोडवते. /etc/apt/apt.conf.d/50unattended-upgrades मध्ये automatic reboot window निश्चित करा आणि reboot अनिश्चित काळासाठी पुढे ढकलू नका. कारण एका वर्षापासून reboot न केलेल्या machine मध्ये जुन्या kernel सोबत अपरीक्षित boot path देखील असतो.

यापैकी कोणत्या तपासण्या सुरक्षितपणे automate करता येतात?

ज्यांचा निर्णय आधीच निश्चित आहे अशा कृती automate करा: security updates, log rotation, certificate renewal आणि scheduled backups. Notification देखील automate करा, जेणेकरून failed unit किंवा भरत चाललेली disk याबद्दल command manually चालविल्याशिवाय तुम्हाला कळेल. Restore test आणि key audit manual ठेवा, कारण परिणाम योग्य आहे का हे ठरवण्यासाठी प्रत्येक वेळी व्यक्तीचे परीक्षण आवश्यक असते. Automation स्वतः कार्यरत आहे का हे तपासणारी एक चाचणीही जोडा. कारण updater शांतपणे fail झाल्यास सर्व काही व्यवस्थित चालू असल्यासारखेच दिसते.