VPS snapshot، backup یا clone: فرق کیا ہے؟

اسنیپ شاٹ، بیک اپ اور کلون دراصل کیا ہوتے ہیں

VPS snapshot آپ کے server کی disk image ہوتی ہے جو آپ کا provider اپنے infrastructure پر، آپ کے account کے اندر محفوظ رکھتا ہے۔ backup آپ کے data کی ایک آزاد copy ہوتی ہے جسے آپ کسی دوسری جگہ restore کر سکتے ہیں، اور اس کے لیے اصل copy رکھنے والے provider کی مدد درکار نہیں ہوتی۔ clone ایک نیا instance ہوتا ہے جو snapshot سے deploy کیا جاتا ہے۔ اس لیے یہ ابتدا ہی سے original کی عین copy ہوتا ہے، identity سمیت۔

یہ تینوں مختلف مسائل حل کرتے ہیں۔ snapshot ناکام upgrade کو چند منٹ میں واپس پچھلی حالت میں لے آتا ہے، لیکن account بند ہونے کی صورت میں یہ کوئی مدد نہیں دیتا۔ backup provider کے ختم ہو جانے کے بعد بھی محفوظ رہتا ہے، لیکن اسے restore کرنے میں زیادہ وقت لگتا ہے کیونکہ پہلے machine دوبارہ بنانی پڑتی ہے۔ clone ایک ہی مرحلے میں دوسرا running server فراہم کرتا ہے، لیکن اس کے نتیجے میں دو ایسی machines بھی بن جاتی ہیں جو خود کو ایک ہی machine سمجھتی ہیں۔

VPS snapshot بیک اپ کیوں نہیں ہوتا

مسئلہ image کا معیار نہیں بلکہ failure domain ہے۔ Snapshot آپ کے provider کے storage platform پر موجود ہوتا ہے، عموماً اسی region میں جہاں سے server لیا گیا تھا، اور ہمیشہ اسی account کے اندر رہتا ہے۔ ایک ہی واقعہ server اور اس کے snapshot دونوں کو متاثر کر سکتا ہے۔

• Account suspend ہو جاتا ہے، payment ناکام ہو جاتی ہے، یا کوئی شخص login چوری کر لیتا ہے۔
• API access رکھنے والا کوئی شخص یا script instance delete کر دیتا ہے۔ بہت سے providers میں instance delete کرنے سے اس کے snapshots بھی delete ہو جاتے ہیں۔ اس کے برعکس فرض کرنے سے پہلے اپنے provider کا documented behaviour پڑھیں۔
• Region میں خرابی پیدا ہوتی ہے اور اس میں موجود ہر چیز بیک وقت unreachable ہو جاتی ہے۔
• Server پر root کے طور پر چلنے والی کوئی چیز /root میں موجود provider API token تلاش کر لیتی ہے اور disk کو متاثر کرنے سے پہلے snapshots حذف کر دیتی ہے۔

بیک اپ وہ copy ہے جو ان چاروں صورتوں کے بعد بھی محفوظ رہتی ہے۔ جانچنے کا سوال صرف ایک ہے: اگر آج دوپہر آپ کا provider account ختم ہو جائے تو آپ اب بھی کیا restore کر سکتے ہیں، اور اسے کہاں restore کریں گے؟ جو چیز اس سوال پر ناکام ہو، وہ rollback tool ہے۔ Snapshots لیتے رہیں، کیونکہ کوئی چیز اس سے زیادہ تیزی سے restore نہیں ہوتی۔ اس کے بعد ایک دوسری copy ایسے storage پر رکھیں جسے آپ کا provider control نہ کرتا ہو۔

پرانا اصول اب بھی درست ہے: data کی تین copies، storage کی دو اقسام پر، جن میں سے ایک platform سے باہر ہو۔ Provider snapshot اور الگ infrastructure پر restic backup repository مل کر یہ ضرورت دو components کے ساتھ پوری کرتے ہیں۔

چلتے ہوئے database کا snapshot بحال ہونے پر خراب کیوں ہو سکتا ہے

Provider snapshot بلاک ڈیوائس کو ایک ہی لمحے کی حالت میں copy کرتا ہے۔ یہ پہلے آپ کی applications کو روکنے کی درخواست نہیں کرتا، اور page cache میں موجود مواد کو نہیں دیکھ سکتا۔ اس لیے زیادہ سے زیادہ یہ image crash-consistent ہوتی ہے۔ یہ بالکل ایسی دکھائی دیتی ہے جیسے کسی نے disk کی power cable نکال دی ہو۔

Stack کا بیشتر حصہ اس صورتِ حال کو سنبھال لیتا ہے۔ ext4 اور XFS mount کے وقت اپنا journal replay کرتے ہیں، اس لیے filesystem دستیاب ہو جاتا ہے۔ PostgreSQL شروع ہوتے وقت اپنا write-ahead log replay کرتا ہے، اور log میں یہ پیغام آتا ہے:

LOG:  database system was not properly shut down; automatic recovery in progress

InnoDB بھی یہی عمل کرتا ہے اور startup کے دوران اپنی crash recovery lines لکھتا ہے۔ یہ recovery database کے design کے مطابق کام کرنے کی علامت ہے، اس لیے خاموش PostgreSQL یا MySQL کے single-volume snapshot کی بحالی عموماً کامیاب رہتی ہے۔

ایسی صورتیں بھی موجود ہیں جہاں crash-consistent ہونا کافی نہیں ہوتا، اور یہی صورتیں زیادہ نقصان پہنچاتی ہیں۔ اگر آپ کا data دو volumes میں پھیلا ہوا ہے تو root disk اور الگ data disk مختلف اوقات میں snapshot ہوتے ہیں۔ اس صورت میں data files اور log directory ایک دوسرے سے مطابقت نہیں رکھتے، اور recovery کے پاس replay کرنے کے لیے درست مواد نہیں ہوتا۔ کوئی بھی file جسے application fsync کو call کیے بغیر لکھتی ہے، مثلاً نصف موصول شدہ upload یا queue file، truncated حالت میں واپس آ سکتی ہے۔ جو data application memory میں رکھتی ہے اور مقررہ وقفے سے flush کرتی ہے، وہ image میں شامل ہی نہیں ہوتا۔

اس لیے snapshot لینے سے پہلے disk پر dump لکھیں۔ اس کے بعد image میں ایک ایسی file موجود ہوگی جس کے اندرونی data کی consistency آپ کو معلوم ہوگی، چاہے live data files کسی بھی حالت میں ہوں۔

sudo -u postgres pg_dumpall --clean --file=/var/backups/pg-$(date +%F).sql
sudo mysqldump --single-transaction --routines --all-databases > /var/backups/mysql-$(date +%F).sql

--single-transaction writers کو block کیے بغیر InnoDB tables کا consistent dump فراہم کرتا ہے، کیونکہ dump ایک repeatable-read transaction کے اندر چلتا ہے۔ یہ MyISAM tables کا احاطہ نہیں کرتا؛ ان کے لیے lock یا stopped server درکار ہوتا ہے۔ Dump پر بھروسا کرنے سے پہلے تصدیق کریں کہ وہ empty یا truncated نہیں ہے: مکمل mysqldump کے آخر میں tail -n 1 /var/backups/mysql-$(date +%F).sql ایک Dump completed comment ہوتا ہے۔

اگر آپ کے پاس الگ data volume ہے تو snapshot کے لیے درکار چند seconds کے دوران اسے freeze کر سکتے ہیں:

sudo fsfreeze -f /srv
# take the snapshot from your provider's panel or API
sudo fsfreeze -u /srv

صرف data volume کو freeze کریں۔ / کو کبھی freeze نہ کریں۔ frozen root filesystem پورے box پر ہر write کو روک دیتا ہے، اس shell سمیت جس سے آپ unfreeze command لکھنے والے ہوں گے۔ یوں آپ خود کو system سے lock out کر لیتے ہیں اور hard reset کا انتظار کرنا پڑتا ہے۔

آف سائٹ حصہ: restic یا Borg

snapshot تیز حصہ ہے۔ آف سائٹ copy وہ حصہ ہے جو آپ کے provider کے متاثر ہونے کے بعد بھی محفوظ رہتا ہے۔ restic ایک اچھا default ہے، کیونکہ یہ deduplication کرتا ہے، client side encryption فراہم کرتا ہے، اور S3-compatible object storage، SFTP یا عام directory میں data لکھتا ہے۔ آف سائٹ target کے طور پر storage VPS اس مقصد کے لیے موزوں ہے، کیونکہ backup repositories کو IOPS کے بجائے capacity درکار ہوتی ہے۔

sudo apt update && sudo apt install -y restic
sudo sh -c 'umask 077; head -c 24 /dev/urandom | base64 > /root/.restic-pass'
sudo chmod 600 /root/.restic-pass
sudo cat /root/.restic-pass

اس passphrase کو ابھی password manager میں محفوظ کریں، اور یہ کام ایسے device پر کریں جو اس server کا حصہ نہ ہو۔ اس passphrase کے بغیر restic repository نہیں کھولی جا سکتی، اور recovery کا کوئی طریقہ موجود نہیں۔ اگر password کی واحد copy اسی box پر تھی جو ابھی ضائع ہوا ہے، تو backup ناقابلِ استعمال encrypted data بن جاتا ہے۔

export RESTIC_REPOSITORY="s3:https://s3.example.com/vps-backups"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
sudo -E restic init
sudo -E restic backup /etc /srv /var/backups
sudo -E restic snapshots

sudo -E ان variables کو برقرار رکھتا ہے، کیونکہ اس کے بغیر root کو صاف environment ملتا ہے اور restic رپورٹ کرتا ہے کہ repository location متعین نہیں کی گئی۔ restic snapshots میں ابھی کی گئی run، اس کے host اور paths کے ساتھ، درج ہونی چاہیے۔ repository کی خود بھی مقررہ schedule کے مطابق تصدیق کریں، اور صرف structure چیک کرنے کے بجائے کچھ data واپس پڑھیں:

sudo -E restic check --read-data-subset=5%
sudo -E restic restore latest --target /tmp/restore-check
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

جس backup کی آزمائش نہ کی گئی ہو، وہ صرف ایک اندازہ ہے۔ کم از کم ایک بار کسی مختلف VPS پر restore کریں، اس میں لگنے والا وقت نوٹ کریں، اور یہ وقت لکھ کر محفوظ رکھیں، کیونکہ یہی آپ کا حقیقی recovery target ہے۔ Borg دوسرا مضبوط انتخاب ہے اور object storage کے بجائے اپنی repository کو SSH کے ذریعے محفوظ کرتا ہے؛ اس کے trade-offs restic اور BorgBackup کا تقابلی جائزہ میں بیان کیے گئے ہیں۔

پروڈکشن کے قریب لے جانے سے پہلے cloned VPS میں کیا درست کریں

Clone ایک عین replica ہوتا ہے۔ یہی اس کی افادیت بھی ہے اور مسئلہ بھی۔ اصل مشین کو منفرد بنانے والی ہر چیز duplicate ہو جاتی ہے، اور duplicates آپس میں ٹکرا سکتے ہیں۔

SSH host keys دوبارہ بنائیں۔ Clone میں اصل مشین کی /etc/ssh/ssh_host_* files موجود ہوتی ہیں، اس لیے دونوں servers ایک ہی host identity پیش کرتے ہیں۔ جس شخص کا ایک server پر control ہو، وہ اس key کو قبول کرنے والے ہر client کے سامنے دوسرے server کی نقالی کر سکتا ہے۔ SSH کوئی warning نہیں دیتا، کیونکہ key وہی ہوتی ہے جس کی client کو توقع تھی۔

sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -A ہر اس type کی نئی key لکھتا ہے جس کی daemon کو توقع ہوتی ہے۔ آخری command سے حاصل ہونے والا fingerprint اصل server کے fingerprint سے مختلف ہونا چاہیے۔ Restart کے بعد آپ کا موجودہ session برقرار رہتا ہے، کیونکہ sshd کو restart کرنے سے قائم connections بند نہیں ہوتے۔ یہ کام کسی کے clone سے connect ہونے سے پہلے کریں۔ اگر آپ اسے بعد کے لیے چھوڑ دیں تو inherited key پر پہلے ہی اعتماد کرنے والے ہر client کو WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! ملے گا، اور اسے پہلے ssh-keygen -R <host> چلانا ہوگا۔

Machine ID تبدیل کریں۔ /etc/machine-id ایک unique identifier ہے جسے systemd پہلی boot پر، صرف ایک بار generate کرتا ہے، اور clone اسے inherit کر لیتا ہے۔

sudo truncate -s 0 /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id
sudo ln -s /etc/machine-id /var/lib/dbus/machine-id
sudo reboot

خالی /etc/machine-id systemd کو اگلی boot پر نئی value generate کرنے کی ہدایت دیتی ہے۔ اسی لیے file کو delete کرنے کے بجائے truncate کیا جاتا ہے۔ اس value کے duplicate ہونے سے دو مسائل پیدا ہوتے ہیں۔ ان images میں جو DHCP سے اپنا address حاصل کرتی ہیں، systemd-networkd بطور default اپنا DHCP client identifier machine ID سے بناتا ہے۔ اس لیے دونوں clones ایک ہی client کے طور پر lease طلب کرتے ہیں اور server انہیں ایک ہی address دے دیتا ہے۔ دوسری طرف journald ہر entry پر machine ID ثبت کرتا ہے، اس لیے central log collector دونوں servers کو ایک ہی machine کے تحت درج کرتا ہے۔ Reboot کے بعد cat /etc/machine-id چلائیں اور تصدیق کریں کہ value تبدیل ہو گئی ہے۔

Hostname تبدیل کریں۔

sudo hostnamectl set-hostname web-02
grep 127.0.1.1 /etc/hosts

hostnamectl /etc/hostname لکھتا ہے اور name کو فوری طور پر لاگو کرتا ہے۔ یہ /etc/hosts کو تبدیل نہیں کرتا، اس لیے 127.0.1.1 line میں بھی مطابقت کے لیے ترمیم کریں۔ اسے چھوڑنے پر نیا name کہیں resolve نہیں ہوتا، اس لیے ہر sudo call failed lookup پر انتظار کرتی ہے اور sudo: unable to resolve host web-02: Name or service not known دکھاتی ہے۔

Image میں شامل ہر credential rotate کریں۔ Clone میں اصل machine کے secrets موجود ہوتے ہیں، اور اب دو machines اصل machine کے طور پر کام کر سکتی ہیں۔ SSH authorized_keys files، provider اور DNS API tokens، application .env files، database passwords، TLS private keys، monitoring enrolment tokens، اور restic repository password کا جائزہ لیں۔ اس command سے ان میں سے زیادہ تر کا پتا چل جاتا ہے:

sudo grep -rIlE 'PASSWORD|SECRET|TOKEN|API_KEY' /etc /srv /opt /home 2>/dev/null
sudo find / -name '.env' -not -path '/proc/*' -not -path '/sys/*' 2>/dev/null

اگر clone ایک test copy ہے جو کبھی traffic serve نہیں کرے گی تو credentials rotate کرنے کے بجائے revoke کریں۔ Live production API token رکھنے والا staging box، کمزور patching والا production box ہی ہوتا ہے۔

وہ jobs بند کریں جو اب دو بار چل رہی ہیں۔ ایک ہی crontab پر چلنے والے دو servers ایک ہی minute میں انہی external systems کو request بھیجتے ہیں۔

systemctl list-timers --all
sudo crontab -l
sudo ls -l /etc/cron.d /etc/cron.daily

restic کا معاملہ تفصیل سے سمجھنا ضروری ہے، کیونکہ یہ صرف واضح failure پیدا نہیں کرتا بلکہ retention کو بھی خراب کرتا ہے۔ restic ہر snapshot پر host name کا tag لگاتا ہے، اور restic forget --keep-daily 7 اپنی policy ہر host کے لیے الگ لاگو کرتا ہے۔ ایک ہی host name report کرنے والی دو machines کو ایک host سمجھا جاتا ہے۔ اس لیے سات "daily" snapshots سب clone سے آ سکتے ہیں، جبکہ اصل machine کے snapshots prune ہو جاتے ہیں۔ پہلی backup run سے پہلے hostname درست کریں، یا clone پر timer روک دیں۔ certbot کا معاملہ آسان ہے: ایک ہی names renew کرنے والے دو servers certificate authority کی duplicate certificate rate limit تک پہنچ جاتے ہیں، اور ناکام run اس error کے ساتھ fail ہوتی ہے کہ names کے اسی مجموعے کے لیے پہلے ہی بہت زیادہ certificates جاری ہو چکے ہیں۔ جس clone کا domain اب بھی اصل server کی طرف point کرتا ہو، وہ HTTP challenge مکمل نہیں کر سکتا۔ اس لیے وہاں renewal disable کریں۔

Monitoring agent کا انتظام کریں۔ زیادہ تر agents hostname یا install کے وقت لکھی گئی ID file سے اپنی شناخت کرتے ہیں۔ اس لیے ایک ہی host کے طور پر report کرنے والے دو agents اپنی metrics کو ایک ہی series میں ملا دیتے ہیں۔ پھر CPU graphs ایسی values دکھاتے ہیں جو کسی ایک machine نے پیدا نہیں کیں، اور alerts بار بار trigger اور clear ہوتی رہتی ہیں۔ Clone پر agent کو stop کرکے remove کریں، یا اپنے vendor کے documented procedure کے مطابق نئے hostname کے تحت دوبارہ enrol کریں۔

Original address کے لیے network configuration چیک کریں۔ اگر image میں netplan کے اندر static address موجود ہو تو clone ایسا IP claim کرے گا جو کسی دوسری machine کا ہے۔

ip -br addr
sudo grep -r addresses /etc/netplan/

اگر یہ clone template بنے گا تو cloud-init state صاف کریں۔

sudo cloud-init clean --logs

اس سے /var/lib/cloud کے تحت cloud-init کی state حذف ہو جاتی ہے، لہٰذا اگلی boot پر first-boot modules دوبارہ چلتے ہیں۔ ان modules میں، جب SSH host keys موجود نہ ہوں، نئی SSH host keys generate کرنا بھی شامل ہے۔ بعض versions machine ID reset کرنے کے لیے ایک flag بھی فراہم کرتے ہیں۔ کسی بیرونی flag list پر اعتماد کرنے کے بجائے اپنی image پر cloud-init clean --help چلائیں تاکہ معلوم ہو سکے کہ آپ کا version کن options کو support کرتا ہے۔

کب کون سا طریقہ استعمال کریں

خطرناک upgrade کو واپس کرنے کے لیے: snapshot لیں۔ تبدیلی سے چند منٹ پہلے snapshot لیں، upgrade چلائیں، اور مسئلہ ہونے پر image restore کریں۔ Restore کے بعد snapshot کے وقت سے اب تک کی تمام writes ختم ہو جاتی ہیں۔ اس لیے live traffic لینے والے server پر پہلے database dump لیں اور واضح طور پر طے کریں کہ آپ کتنے وقت کا data کھو سکتے ہیں۔ کسی ایسے server کے لیے جسے آپ دس منٹ کے لیے offline کر سکتے ہوں، do-release-upgrade میں snapshot ہی مکمل منصوبہ ہوتا ہے۔

بڑے plan پر منتقل ہونے کے لیے: clone deploy کریں۔ Snapshot سے بڑے plan پر clone بنائیں، اوپر دی گئی identity فہرست کے تمام نکات مکمل کریں، پھر traffic منتقل کرنے سے پہلے اسے اس کے اپنے IP پر test کریں۔ Cutover کو تیز رکھنے کے لیے ایک دن پہلے DNS TTL کم کریں، اور اصل server کو اس وقت تک چلتا رہنے دیں جب تک نئے server نے حقیقی traffic سنبھال نہ لیا ہو۔ پہلے تصدیق کریں کہ بڑا plan واقعی آپ کے workload کے لیے تیز ہے۔ اس مقصد کے لیے دونوں servers پر یکساں benchmark طریقہ استعمال کریں، کیونکہ زیادہ مصروف hardware پر زیادہ vCPUs ہمیشہ upgrade نہیں ہوتے۔

Template بنانے کے لیے: صاف کی گئی machine کا snapshot لیں۔ ایک server install اور harden کریں، پھر image بنانے سے پہلے اس سے ہر منفرد چیز ہٹا دیں۔ Host keys نہ ہوں، machine ID خالی ہو، ذاتی authorized_keys نہ ہو، credentials موجود نہ ہوں، اور cloud-init صاف کیا گیا ہو۔ اس کا snapshot لیں۔ اس سے deploy ہونے والا ہر instance پہلی boot پر اپنی identity بناتا ہے، اس لیے اوپر دی گئی checklist دوبارہ checklist نہیں رہتی۔ اسے نئے VPS کے پہلے دس منٹ کا معیاری طریقہ کے ساتھ استعمال کریں تاکہ template میں وہ کام پہلے ہی شامل ہو جو بصورت دیگر آپ کو ہر بار دہرانا پڑتا۔

FAQ

کیا VPS snapshot backup ہوتا ہے؟

نہیں، کیونکہ یہ اسی failure domain میں ہوتا ہے جس میں اصل server موجود ہے۔ Snapshot آپ کے provider کی storage پر، آپ کے account میں، عموماً اسی region میں موجود ہوتا ہے۔ Account suspension، چوری شدہ API key، یا instance کو غلطی سے delete کرنا server اور اس کے snapshots دونوں کو ایک ہی کارروائی میں ختم کر سکتا ہے۔ بہت سے providers کے ہاں instance delete کرنے سے اس کے snapshots بھی design کے مطابق delete ہو جاتے ہیں۔ Snapshot آپ کے پاس موجود تیز ترین rollback طریقہ ہے، اس لیے snapshots بناتے رہیں، اور دوسری encrypted copy ایسے infrastructure پر بھی رکھیں جسے آپ کا provider control نہ کرتا ہو۔

کیا snapshot لینے سے پہلے database کو روکنا ضروری ہے؟

ہمیشہ نہیں، لیکن حاصل ہونے والی حالت کو قبول کرنا ضروری ہے۔ Provider snapshot crash-consistent ہوتا ہے۔ اس کا مطلب ہے کہ image ویسی ہوتی ہے جیسی power cut کے بعد disk نظر آتی۔ PostgreSQL اور InnoDB start ہونے پر اس حالت سے recover کر لیتے ہیں، اور PostgreSQL اس دوران database system was not properly shut down; automatic recovery in progress logs میں لکھتا ہے۔ Recovery کی ضمانت نہیں ہوتی جب data دو volumes میں موجود ہو جن کے snapshots مختلف اوقات میں لیے گئے ہوں، یا جب کوئی application fsync کے بغیر write کرتی ہو۔ پہلے disk پر pg_dumpall یا mysqldump --single-transaction لکھیں، تاکہ image میں ایسی ایک file موجود ہو جس کے consistent ہونے کا آپ کو یقین ہو۔

دو cloned servers ایک ہی IP address کے لیے کیوں لڑتے ہیں؟

کیونکہ دونوں میں /etc/machine-id مشترک ہوتا ہے۔ DHCP استعمال کرنے والی images میں systemd-networkd بطور default اپنا DHCP client identifier machine ID سے بناتا ہے۔ اس لیے دونوں clones ایک ہی client کے طور پر lease طلب کرتے ہیں، اور DHCP server دونوں کو ایک ہی address فراہم کرتا ہے۔ /etc/machine-id کو zero bytes تک truncate کریں، /var/lib/dbus/machine-id کو remove کریں، اسے واپس /etc/machine-id سے symlink کریں، اور reboot کریں تاکہ systemd نئی value بنائے۔ دوسری عام وجہ /etc/netplan/ میں درج static address ہے، جسے clone نے جوں کا توں نقل کر لیا ہے۔ ip -br addr سے تصدیق کریں۔

یہ جانچنے کا تیز ترین طریقہ کیا ہے کہ clone کو production میں رکھنا محفوظ ہے؟

اصل server کے مقابلے میں چار چیزوں کا موازنہ کریں۔ دونوں پر ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub چلائیں اور تصدیق کریں کہ fingerprints مختلف ہیں۔ دونوں پر cat /etc/machine-id چلائیں اور تصدیق کریں کہ values مختلف ہیں۔ hostnamectl status چلائیں اور تصدیق کریں کہ name نیا ہے اور resolve ہو رہا ہے، تاکہ sudo warning نہ دے۔ پھر systemctl list-timers --all چلائیں اور ہر اس timer کو روک دیں جو کسی shared system سے رابطہ کرتا ہے، مثلاً backups، certificate renewal، یا monitoring agent، جب تک یہ فیصلہ نہ ہو جائے کہ یہ job کس machine کی ذمہ داری ہے۔