Docker یا Kubernetes پروڈکشن والیوم کو حذف کر دیا گیا: بچایا جا رہا ہے۔ docker system prune --volumes، overlay2 انوڈس، اور etcd سنیپ شاٹس¶

چل رہا ہے۔ docker compose down -v، docker system prune -a --volumes، docker volume rm، یا kubectl delete pvc پروڈکشن میں غلط ٹرمینل ٹیب پر لائیو PostgreSQL، MySQL، MariaDB، Redis، MongoDB، یا SQLite ڈیٹا بیس والیوم کو صاف کرنے کے تیز ترین طریقوں میں سے ایک ہے۔ کلاؤڈ ورچوئل مشین سنیپ شاٹس کے برعکس جو 7 دن کے ری سائیکل بن میں منتقل ہوتے ہیں، ڈوکر کا مقامی والیوم ڈرائیور (/var/lib/docker/volumes/<name>/_data) اور کبرنیٹس local-path / hostPath فراہم کنندگان فوری طور پر معیاری POSIX جاری کرتے ہیں۔ unlink() اور rmdir() بنیادی لینکس ہوسٹ فائل سسٹم کے خلاف براہ راست کال کرتا ہے (ext4، XFS، یا Btrfs)۔ کمانڈ ختم ہونے کے بعد اس لینکس ہوسٹ پر ہونے والی ہر تحریر ڈسک پر آزاد ڈیٹا بیس بلاکس کو اوور رائٹ کر سکتی ہے۔ اگر آپ کی سرور ڈسک 100 فیصد بھری ہوئی ہے (0 bytes freeاس سے پہلے کہ کوئی بھاگے۔ docker system prune --volumes گھبراہٹ میں، مشورہ سرور ڈسک 100% مکمل، ڈیٹا بیس WAL لاگ بلوٹ، اور صفر اسپیس ریکوری; کنٹینرز کے باہر ننگی دھاتی لینکس فائل کو حذف کرنے کے لیے، دیکھیں ext4، XFS، APFS، اور NTFS پر حادثاتی rm -rf یا Shift-Delete: صرف پڑھنے کے لیے ریماؤنٹ اور inode carving اور ورچوئل مشین VMDK، VHDX، اور qcow2 سنیپ شاٹ چین بدعنوانی اور ہائپر وائزر ریسکیو. اگر یہ پیداواری بندش ہسپتال کے مریضوں کی دیکھ بھال، ایمرجنسی ڈسپیچ، یا پبلک یوٹیلیٹی سیفٹی سسٹم کو متاثر کرتی ہے، تو اپنے مقامی ایمرجنسی نمبر پر کال کریں (911 ریاستہائے متحدہ اور کینیڈا میں، 112 یورپی یونین بھر میں، 999 برطانیہ میں) یا ہماری ڈائرکٹری چیک کریں۔ ہنگامی نمبر.

اب یہ کرو¶

1. ** مت بھاگو docker compose up -d، systemctl restart docker، یا کوبرنیٹس پوڈ کو دوبارہ تعینات کریں**: کنٹینر کو دوبارہ بنانا یا ڈوکر ڈیمون کو دوبارہ شروع کرنا میگا بائٹس کا نیا لکھتا ہے۔ overlay2 میٹا ڈیٹا، کنٹینر JSON لاگز، اور تازہ شروع کردہ خالی ڈیٹا بیس فائلیں (initdb) براہ راست عین مطابق ext4 یا XFS بلاکس جہاں آپ کا حذف شدہ حجم سیکنڈ پہلے بیٹھا تھا۔
2. ** 5 سیکنڈ میں چیک کریں اگر کنٹینر کا عمل (postgres، mysqld، redis-server، node، python) اب بھی میموری میں چل رہا ہے (ps aux اور sudo lsof +L1)**: اگر کسی نے ماؤنٹڈ والیوم کے اندر فائلیں ڈیلیٹ کیں یا کنٹینر کے چلنے کے دوران کسی گمنام والیوم کو ان لنک کر دیا، تو لینکس کرنل 100 فیصد ان لنک شدہ ڈیٹا بیس فائلوں کو ڈسک پر زندہ رکھتا ہے جب تک کہ کنٹینر کی میزبان پروسیس ID (PID) ایک کھلا فائل ڈسکرپٹر رکھتا ہے (FD)۔ آپ ان فائلوں کو براہ راست باہر کاپی کر سکتے ہیں۔ /proc/<PID>/fd/ یا /proc/<PID>/root/ کنٹینر کے رکنے سے پہلے صفر ڈیٹا کے نقصان کے ساتھ۔
3. ** اگر کنٹینر پہلے ہی روک دیا گیا ہے اور حجم کو حذف کردیا گیا ہے (docker compose down -v یا docker system prune --volumes)، منجمد میزبان ڈسک فوری طور پر لکھتا ہے**: ڈاکر ڈیمون کو روکیں (sudo systemctl stop docker.socket docker.service containerd) پس پس منظر کے کنٹینرز اور ہیلتھ چیکس لاگ ان لکھنا بند کر دیتے ہیں۔ /var/lib/docker، پھر یا تو دوبارہ ماؤنٹ کریں۔ /var/lib/docker (یا جڑ / تقسیم) صرف پڑھنے کے لیے (sudo mount -o remount,ro /) یا فوری طور پر بلاک لیول کلاؤڈ والیوم اسنیپ شاٹ لیں (AWS EBS Snapshot، GCP Persistent Disk Snapshot، DigitalOcean Volume Snapshotکسی بھی چیز کو چھونے سے پہلے۔
4. ** اگر آپ Kubernetes پر ہیں (kubectl delete pvc یا kubectl delete namespace) پرسسٹنٹ والیوم چیک کریں (PV) ReclaimPolicy (kubectl get pv)فوری طور پر**:
5. اگر PV تھا persistentVolumeReclaimPolicy: Retainآپ کا ڈیٹا ڈیلیٹ نہیں ہوا: the PV بس منتقل کر دیا گیا Released حیثیت اور آپ کی کلاؤڈ ڈسک (EBS، Azure Disk، Ceph RBD، NFS) 100 فیصد برقرار ہے۔
6. یہاں تک کہ اگر kubectl delete pvc میں پھنس گیا ہے Terminating، Kubernetes ** فائنلائزر (kubernetes.io/pvc-protection)** CSI ڈرائیور کو بنیادی اسٹوریج کو حذف کرنے سے روکیں جب تک کہ کوئی Pod اب بھی اس PVC کا حوالہ دیتا ہے۔ Pod کو اس وقت تک حذف نہ کریں جب تک کہ آپ چلنے والے Pod سے ڈیٹا کو کاپی نہ کر لیں۔
7. اندرونی بلاک پارٹیشن کی تصویر (dd / ddrescue SSH سے زیادہ) ایک بیرونی ڈسک پر یا چلانے سے پہلے کلاؤڈ والیوم کو الگ کریں۔ ext4magic، extundelete، یا PhotoRec: کبھی بھی فائل کارور نہ چلائیں جو آؤٹ پٹ فائلوں کو اسی ڈسک پارٹیشن پر لکھیں جہاں سے آپ بازیافت کر رہے ہیں۔ /var/lib/docker/volumes.
8. ** خراب شدہ یا اتفاقی طور پر مٹ جانے والی Kubernetes کلسٹر حالت کے لیے (kubectl delete crd / namespace)، روکو kube-apiserver اور اپنا تازہ ترین بحال کریں۔ etcd سنیپ شاٹ (etcdctl snapshot restore)**: اگر کلسٹر ریاست میں ہے۔ etcd کو صاف کر دیا گیا تھا جب کہ کلاؤڈ اسٹوریج کی بنیادی حجم اب بھی موجود ہے، بحال ہو رہی ہے۔ etcd سب کو بحال کرتا ہے PV، PVC، Secret، اور ConfigMap ایک ساتھ اشیاء.

فیصلہ درخت: ڈوکر والیوم کو حذف کر دیا گیا، overlay2 پرت، یا Kubernetes PVC triage¶

اس فلو چارٹ کا استعمال اس بنیاد پر کریں کہ آیا کنٹینر کا عمل اب بھی زندہ ہے، آیا حجم کو مقامی ڈسک یا کلاؤڈ CSI اسٹوریج کی طرف سے حمایت حاصل ہے، اور کون سا فائل سسٹم میزبانی کرتا ہے /var/lib/docker:

flowchart TD
    Start["ڈوکر یا کبرنیٹس ڈیلیٹ کمانڈ کے بعد پروڈکشن ڈیٹا غائب ہے۔"] --> WhichEnv{"کس پلیٹ فارم اور کمانڈ نے نقصان کو جنم دیا؟"}

    WhichEnv -->|"ڈوکر: کنٹینر ابھی بھی چل رہا ہے (فائلیں حجم/کنٹینر کے اندر سے منسلک ہیں)"| ProcRescue["بچاؤ unlinked فائل ڈسکرپٹرس کو sudo lsof +L1 اور /proc/PID/fd/N یا /proc/PID/root/ کے ذریعے کھولیں"]

    WhichEnv -->|"ڈوکر: کنٹینر روکا گیا اور حجم کو حذف کر دیا گیا (کمپوز ڈاون -v / prune --volumes)"| StopDocker["فوری طور پر چلائیں: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl حذف pvc / pv / statefulset / namespace"| K8sCheck{"کیا پوڈ اب بھی چل رہا ہے یا پی وی سی ختم ہونے میں پھنس گیا ہے؟"}

    K8sCheck -->|"ہاں: پوڈ ابھی بھی چل رہا ہے (فائنلائزر بلاک کرنے والا CSI ڈیلیٹ)"| K8sExec["پوڈ کو حذف نہ کریں -> kubectl exec/pg_dump/tar stdout پر فوری طور پر لوکل ڈسک پر چلائیں"]
    K8sCheck -->|"نہیں: Pod Gone -> چیک کریں kubectl get pv"| ReclaimCheck{"PV ReclaimPolicy کیا تھی؟"}

    ReclaimCheck -->|"برقرار رکھیں (PV اسٹیٹس = جاری)"| ClearClaimRef["100% ڈیٹا برقرار -> spec.claimRef.uid کو ہٹانے کے لیے PV میں ترمیم کریں -> نئے PVC سے دوبارہ منسلک کریں"]
    ReclaimCheck -->|"حذف کریں (کلاؤڈ EBS / PD / Longhorn / Local-path)"| CloudOrLocal{"کلاؤڈ CSI والیوم یا لوکل ہوسٹ ڈسک؟"}

    CloudOrLocal -->|"کلاؤڈ CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Cloud Console Recycle Bin / خودکار EBS سنیپ شاٹس / Ceph RBD Trash (rbd trash ls) چیک کریں"]
    CloudOrLocal -->|"لوکل نوڈ ڈسک (لوکل پاتھ / ہوسٹ پاتھ)"| StopDocker

    StopDocker --> RemountRO["ریماؤنٹ ہوسٹ پارٹیشن صرف پڑھنے کے لیے (mount -o remount,ro) یا SSH پر سٹریم بلاک امیج"]
    RemountRO --> HostFS{"کس فائل سسٹم کی میزبانی کرتا ہے /var/lib/docker؟"}
    HostFS -->|"ext4"| Ext4Rec["debugfs / ext4magic Journal Inode Transaction Rollback استعمال کریں (-ایک ٹائم اسٹیمپ)"]
    HostFS -->|"ایکس ایف ایس / بی ٹی آر ایف"| CarveRec["SQLite، Postgres Heap، یا InnoDB .ibd کے لیے Btrfs Roots / xfs_irecover / حسب ضرورت دستخطی نقش کاری کا استعمال کریں"]

مرحلہ 1: ڈوکر اور کبرنیٹس دراصل ڈسک پر والیوم کو کیسے حذف کرتے ہیں۔¶

کوئی بھی ریکوری کمانڈ چلانے سے پہلے، یہ سمجھ لیں کہ آپ کا ڈیٹا جسمانی طور پر لینکس ہوسٹ پر کہاں رہتا ہے اور ڈیلیٹ کمانڈ نے اصل میں کیا چھوا ہے:

مرحلہ 2: کھلے ڈیٹا بیس فائلوں کو اب بھی چلنے والے کنٹینر سے بچانا (/proc/<pid>/fd/)¶

انتظار کریں: کیا کنٹینر ابھی بھی چل رہا ہے؟ اکثر، ایک انجینئر ایپلیکیشن مائیگریشن اسکرپٹ، کلین اپ کرون جاب، یا مینوئل چلاتا ہے۔ rm -rf /var/lib/postgresql/data/* یا rm /app/data/production.sqlite3 چلتے ہوئے کنٹینر کے اندر، یا بنیادی میزبان بائنڈ ماؤنٹ فولڈر کو حذف کر دیتا ہے۔ /opt/app/data جبکہ کنٹینر خود (postgres، mysqld، mariadbd، redis-server، mongod، gunicorn، node) ابھی تک جاری ہے ہے۔

لینکس میں، جب فائل ڈسک سے ڈیلیٹ نہیں ہوتی rm یا unlink() کہا جاتا ہے. اس کے ڈسک بلاکس اور انوڈ 100 فیصد مختص اور پڑھنے کے قابل رہتے ہیں جب تک کہ ایک اوپن فائل ڈسکرپٹر (FD) اس inode پر اسے بند کرتا ہے یا باہر نکل جاتا ہے۔

مرحلہ 1: میزبان پروسیس ID تلاش کریں (PID) کنٹینر کے عمل کا¶

لینکس ہوسٹ نوڈ پر (کنٹینر کے اندر نہیں)، میزبان کو تلاش کریں۔ PID آپ کے ڈیٹا بیس یا درخواست کے عمل کا:

sudo lsof +L1 | grep -E "postgres|mysqld|mariadbd|sqlite|redis|mongo|node|python|java"

COMMAND     PID   USER   FD   TYPE DEVICE  SIZE/OFF NLINK    NODE NAME
mysqld    18492    999   14u   REG  259,1 482344960     0 1849201 /var/lib/mysql/app_prod/users.ibd (deleted)
mysqld    18492    999   15u   REG  259,1 125829120     0 1849202 /var/lib/mysql/app_prod/orders.ibd (deleted)
mysqld    18492    999   16u   REG  259,1  79691776     0 1849190 /var/lib/mysql/ibdata1 (deleted)
python3   22104   1000    4u   REG  259,1  89128960     0 3102944 /data/production.sqlite3 (deleted)

مرحلہ 2: غیر منسلک ڈیٹا بیس فائلوں کو سیدھے باہر کاپی کریں۔ /proc/<PID>/fd/¶

کنٹینر کو نہ روکیں یا دوبارہ شروع کریں۔ جب یہ عمل ابھی بھی چل رہا ہے، خام فائل ڈسکرپٹرز کو براہ راست اپنے میزبان پر محفوظ فولڈر میں کاپی کریں:

sudo mkdir -p /root/proc_emergency_rescue

# Example 1: Rescuing an unlinked SQLite3 database (PID 22104, FD 4)
sudo cp /proc/22104/fd/4 /root/proc_emergency_rescue/production.sqlite3
# Check if PID 22104 also holds the -wal file open (e.g. FD 5) and copy it too:
sudo cp /proc/22104/fd/5 /root/proc_emergency_rescue/production.sqlite3-wal

# Example 2: Automatically rescuing ALL open (deleted) MySQL/Postgres files for PID 18492
for fd in /proc/18492/fd/*; do
    target=$(sudo readlink "$fd" 2>/dev/null)
    if echo "$target" | grep -q "(deleted)"; then
        fd_num=$(basename "$fd")
        clean_name=$(echo "$target" | sed 's/ (deleted)//; s/\//_/g')
        echo "Rescuing FD $fd_num -> $clean_name"
        sudo cp "$fd" "/root/proc_emergency_rescue/${fd_num}${clean_name}"
    fi
done

مرحلہ 3: اس سے بھی بہتر: لائیو منطقی ڈمپ چلائیں (pg_dump / mysqldump / .backup) کنٹینر FDs کو بند کرنے سے پہلے¶

اگر postgres یا mysqld اب بھی اس کی ڈیٹا فائلوں کو میموری میں کھولنے کے ساتھ چل رہا ہے اور /proc/<PID>/fd/پہلے موجودہ یونکس ساکٹ یا TCP کنکشن پر لائیو لاجیکل ڈمپ چلانے کی کوشش کریں:

# If the database engine can still read its open file descriptors:
docker exec <container_name> pg_dumpall -U postgres > /root/proc_emergency_rescue/live_dump.sql
# Or for MySQL:
docker exec <container_name> mysqldump -u root -p --all-databases --single-transaction > /root/proc_emergency_rescue/live_mysql.sql

فیز 3: ڈیلیٹ شدہ ڈوکر والیوم کو آن کرنا ext4 یا XFS کنٹینر بند ہونے کے بعد¶

اگر آپ بھاگ گئے تو کیا ہوگا؟ docker compose down -v یا docker system prune --volumes، تو کنٹینر پہلے ہی روکا ہوا ہے اور سب /proc/<pid>/fd/ وضاحت کرنے والے بند ہیں؟ اب آپ لینکس ہوسٹ پر بیک گراؤنڈ ڈسک لکھنے کے خلاف دوڑ میں ہیں۔

مرحلہ 1: لینکس ہوسٹ فائل سسٹم کو 10 سیکنڈ کے اندر منجمد کریں۔¶

1. ڈاکر، کنٹینر، کبلیٹ، اور کرون کو فوری طور پر روکیں اس لیے کوئی کنٹینر، ہیلتھ چیک، یا لاگ روٹیٹر کوئی اور بائٹ نہیں لکھتا /var/lib/docker:

   sudo systemctl stop docker.socket docker.service containerd.service cron.service
   

2. ** چیک کریں کہ کون سا بلاک ڈیوائس اور فائل سسٹم رکھتا ہے۔ /var/lib/docker**:

   df -Th /var/lib/docker
   

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/nvme0n1p1 ext4  100G   42G   58G  42% /
   

3. پارٹیشن کو صرف پڑھنے کے لیے دوبارہ ماؤنٹ کریں (یا کسی خام پارٹیشن کی تصویر کو SSH پر دوسری مشین پر سٹریم کریں):
4. اگر /var/lib/docker اس کے اپنے وقف شدہ تقسیم یا LVM والیوم پر ہے (مثال کے طور پر /dev/nvme0n1p2 یا /dev/mapper/vg0-docker)، اسے فوری طور پر صرف پڑھنے کے لیے دوبارہ ماؤنٹ کریں:

   sudo mount -o remount,ro /var/lib/docker
   

5. اگر /var/lib/docker جڑ پر ہے / تقسیم (/)، kernel Magic SysRq ٹرگر (echo u | sudo tee /proc/sysrq-trigger) یا sudo mount -o remount,ro /.
6. **اگر آپ کلاؤڈ VPS پر ہیں (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): فوری طور پر اپنے کلاؤڈ ویب کنسول پر جائیں اور سرور کے بلاک والیوم پر اسنیپ شاٹ بنائیں پر کلک کریں (یا SSH پر خام بلاک ڈیوائس کو دوسرے سرور پر سٹریم کریں: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz")۔

مرحلہ 2: چیک کریں کہ آیا آپ کا ڈیٹا اب بھی کسی اور غیر منقطع والیوم میں بیٹھا ہے یا overlay2 پرت¶

غیر مختص شدہ ڈسک بلاکس کو تراشنے سے پہلے، اس بات کی تصدیق کریں کہ آپ کا ڈیٹا بیس درحقیقت بائنڈ ماؤنٹ یا کسی مختلف نام والی والیوم میں محفوظ نہیں تھا جو بچ گیا:

# Search the entire /var/lib/docker tree read-only for any surviving database files:
sudo find /var/lib/docker -name "PG_VERSION" -o -name "ibdata1" -o -name "*.sqlite*" -o -name "*.db" -o -name "dump.rdb" -o -name "WiredTiger" 2>/dev/null

مرحلہ 3: غیر لنک شدہ ڈوکر والیوم ڈائریکٹریز کو بحال کرنا آن ext4 کا استعمال کرتے ہوئے ext4 جرنل (ext4magic اور debugfs)¶

جب docker volume rm حذف کرتا ہے /var/lib/docker/volumes/<vol_name>/_data ایک پر ext4 فائل سسٹم، ext4 براہ راست بلاک پوائنٹرز کو صفر کریں (i_block / حد تک درخت کی جڑ) لائیو انوڈ ٹیبل میں۔ تاہم، ext4 جرنل (انوڈ <8>، عام طور پر 128 MB کو 1024 MB سرکلر رِنگ بفر) اب بھی عین پہلے سے عین مطابق انوڈ ٹیبلز اور ڈائریکٹری بلاکس کی تاریخی کاپیاں رکھتا ہے docker compose down -v پھانسی دی گئی.

+-------------------------------------------------------------------------+
| HOW ext4magic RECOVERS A DELETED DOCKER VOLUME FROM THE EXT4 JOURNAL    |
|                                                                         |
| Live Inode Table on Disk (After docker volume rm):                      |
|   Inode #918402 (users.ibd): [Size = 0, Extent Pointers = ZEROED]       |
|                                                                         |
| Ext4 Journal Ring Buffer (Inode <8> on Disk):                           |
|   Transaction #41902 (10 mins ago):                                     |
|   Inode #918402 (users.ibd): [Size = 482MB, Extents = Blocks 9000..9999]|
|                                                                         |
| -> ext4magic reads the old Inode Copy from Journal Transaction #41902   |
|    and extracts Blocks 9000..9999 directly to your rescue drive.        |
+-------------------------------------------------------------------------+

دوڑو ext4magic آپ کے صرف پڑھنے کی تقسیم کے خلاف (یا .img اسنیپ شاٹ کاپی دوسرے سرور پر، ٹائم اسٹیمپ کی وضاحت کرتے ہوئے (-a) آپ کے بھاگنے سے 5 منٹ پہلے سے docker compose down -v یا docker system prune --volumes:

# Install ext4magic on your rescue machine (never on the affected partition)
sudo apt-get install -y ext4magic e2fsprogs

# Dump the ext4 journal from the frozen partition / image to a file in RAM (/dev/shm)
sudo debugfs -R "dump <8> /dev/shm/ext4_journal.copy" /dev/nvme0n1p1

# Recover all files deleted under var/lib/docker/volumes after (Current Time - 15 minutes)
sudo mkdir -p /mnt/external_rescue/docker_recovered
sudo ext4magic /dev/nvme0n1p1 \
  -j /dev/shm/ext4_journal.copy \
  -f var/lib/docker/volumes \
  -a $(date -d "-15 minutes" +%s) \
  -r -d /mnt/external_rescue/docker_recovered

مرحلہ 4: خام SQLite، PostgreSQL، یا MySQL InnoDB فائلوں کو تراشنا جب جریدہ لپیٹ جاتا ہے (XFS یا ext4)¶

اگر میزبان استعمال کرتا ہے XFS یا اگر ext4 جرنل پہلے سے ہی انوڈ پوائنٹرز پر لپیٹا ہوا ہے، خام ڈسک کی تصویر کے خلاف دستخط اور ڈھانچے کی نقش و نگار کا استعمال کریں (docker_host_raw.img):

1. ** SQLite3 ڈیٹا بیس کے لیے (.sqlite، .db - جیسے، والٹ وارڈن، نیکسٹ کلاؤڈ، ہوم اسسٹنٹ، گیٹا، گرافانا)**: ہر SQLite3 ڈیٹابیس اپنے پہلے 4 کلو بائٹ صفحہ کے بائٹ 0 پر ایک غیر واضح 16-بائٹ ASCII ہیڈر کے ساتھ شروع ہوتا ہے: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0")، اور درست ڈیٹا بیس صفحہ کا سائز ذخیرہ کرتا ہے (Bytes 16..17، عام طور پر 4096) اور صفحات میں ڈیٹا بیس کا کل سائز (Bytes 28..31, big-endian 32-bit integer) بالکل اسی ہیڈر کے اندر۔
2. دوڑو PhotoRec کے ساتھ [File Opt] -> [x] sqlite فعال، یا تقسیم کو براہ راست اسکین کریں۔ grep -ab "SQLite format 3" اپنی حذف شدہ SQLite فائل کے عین مطابق بائٹ آفسیٹ کو تلاش کرنے اور اسے نکالنے کے لیے dd:

   # Find the exact byte offsets of every "SQLite format 3" header on the partition:
   sudo grep -ab "SQLite format 3" /dev/nvme0n1p1
   

   ایک بار نکالا، چلائیں sqlite3 carved.db ".recover" | sqlite3 repaired.db بی ٹری کے ہر برقرار پتے کے صفحے کو دوبارہ تشکیل دینا۔

1. ** MySQL / MariaDB InnoDB کے لیے (.ibd ٹیبل فائلیں)**: ہر InnoDB .ibd جدول ترتیب وار پر مشتمل ہے۔ 16 KB (16,384 بائٹ) صفحات پر مشتمل ہے۔ FIL_PAGE_INDEX (0x45BF) ہیڈر اور ٹیبل منفرد ہے۔ space_id. Percona / TwinDB استعمال کریں undrop-for-innodb (stream_parser + c_parser) اسکین کرنے کے لیے ٹول کٹ /dev/nvme0n1p1 سب کے لیے 16 KB InnoDB انڈیکس صفحات اور ہر قطار کو براہ راست TSV/SQL فائلوں میں دوبارہ درآمد کرنے کے لیے پھینک دیں۔
2. ** PostgreSQL ہیپ فائلوں کے لیے ($PGDATA/base/<db_oid>/<relfilenode>)**: PostgreSQL ہر ٹیبل کو ملحقہ کے طور پر اسٹور کرتا ہے۔ 8 KB (8,192 بائٹ) ہیپ صفحات پر مشتمل ہے۔ PageHeaderData (pd_lower، pd_upper، pd_special)۔ استعمال کریں pg_filedump یا pglazarus / pdu غیر مختص شدہ ڈسک کے علاقوں کو اسکین کرنے کے لیے 8 KB آپ کے ٹیبل کے کالم ٹیپل لے آؤٹ سے مماثل صفحات (HeapTupleHeaderData) اور قطاروں کو دوبارہ تشکیل دیں۔

مرحلہ 4: Kubernetes PVC، PV، اور etcd سنیپ شاٹ ایمرجنسی ریکوری¶

Kubernetes میں (EKS، GKE، AKS، k3s، RKE2، kubeadm، OpenShift)، غلطی سے ایک PersistentVolumeClaim کو حذف کرنا (kubectl delete pvc)، ایک StatefulSet، یا ایک پورا Namespace (kubectl delete ns prod) اسٹینڈ اسٹون ڈوکر سے بہت مختلف فن تعمیر کی پیروی کرتا ہے۔

منظر A: PVC دکھاتا ہے۔ Terminating (فائنلائزر لائف سیور)¶

چلائیں:

kubectl get pvc -n <namespace>

# Stream a compressed tar backup or pg_dump out of the still-running pod immediately:
kubectl exec -n <namespace> <pod-name> -- pg_dumpall -U postgres > ./rescued_k8s_db.sql
# Or tar an entire mounted volume directory out over stdout:
kubectl exec -n <namespace> <pod-name> -- tar czf - /var/lib/postgresql/data > ./rescued_pvc_files.tar.gz

منظرنامہ B: PVC کو حذف کر دیا گیا تھا، اور kubectl get pv میں پرسسٹنٹ والیوم دکھاتا ہے۔ Released ریاست (ReclaimPolicy: Retain)¶

چلائیں:

kubectl get pv

ایک بنانے کا طریقہ Released پی وی Available صفر ڈیٹا کے نقصان کے ساتھ 10 سیکنڈ میں دوبارہ: 1. PersistentVolume آبجیکٹ میں ترمیم کریں اور حذف کریں۔ spec.claimRef بلاک:

kubectl patch pv <your-pv-name> --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

منظر نامہ C: ایک سے مسح شدہ Kubernetes کلسٹر حالت کو بحال کرنا etcd سنیپ شاٹ (etcdctl snapshot restore)¶

اگر کوئی بھاگ گیا تو کیا ہوگا؟ kubectl delete namespace prod یا helm uninstall اور 200 Kubernetes مینی فیسٹس، سیکرٹس، کنفیگ میپس، اور PV تعریفوں کو ایک خود سے منظم پر مٹا دیا۔ kubeadm، k3s، یا RKE2 کنٹرول ہوائی جہاز؟

1. ** اپنی تازہ ترین تلاش کریں۔ etcd سنیپ شاٹ** (بطور ڈیفالٹ میں /var/lib/rancher/k3s/server/db/snapshots/، /var/lib/rancher/rke2/server/db/snapshots/، یا آپ کا شیڈول /var/backups/etcd/snapshot.db)۔
2. لائیو کلسٹر کو چھونے سے پہلے سنیپ شاٹ کی سالمیت کی تصدیق کریں:

   ETCDCTL_API=3 etcdctl snapshot status /path/to/snapshot.db --write-out=table
   

3. رکو kube-apiserver اور etcd کنٹرول پلین نوڈ پر:
4. پر kubeadm (جامد پھلی): منتقل کریں۔ /etc/kubernetes/manifests/kube-apiserver.yaml اور /etc/kubernetes/manifests/etcd.yaml عارضی طور پر /root/manifests_hold/ تو kubelet دونوں کنٹینرز کو صاف طور پر روکتا ہے، پھر بیک اپ /var/lib/etcd کو /var/lib/etcd.bak.
5. پر k3s: بھاگو sudo systemctl stop k3s اور sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** بحال کریں۔ etcd ڈیٹا ڈائریکٹری آن kubeadm**:

   sudo ETCDCTL_API=3 etcdctl snapshot restore /path/to/snapshot.db \
     --data-dir=/var/lib/etcd \
     --name=<control-plane-node-name> \
     --initial-cluster=<node-name>=https://<node-ip>:2380 \
     --initial-advertise-peer-urls=https://<node-ip>:2380
   

7. منتقل etcd.yaml اور kube-apiserver.yaml واپس میں /etc/kubernetes/manifests/. 30 سیکنڈ کے اندر، kube-apiserver بحال شدہ سے دوبارہ جوڑتا ہے۔ etcd اسٹور اور ہر حذف شدہ نام کی جگہ، خفیہ، کنفیگ میپ، اور پرسسٹنٹ والیوم آبجیکٹ دوبارہ ظاہر ہوتا ہے۔

مرحلہ 5: ڈوکر اور کبرنیٹس کی جلدوں کو حادثاتی طور پر حذف کرنے کے خلاف سخت کرنا¶

ایک بار جب آپ کا پروڈکشن ڈیٹا بیس بحال ہو جائے تو، ان چار آرکیٹیکچرل گارڈریلز کو لاگو کریں تاکہ ایک سی ایل آئی ٹائپو دوبارہ کبھی بھی لائیو والیوم کو حذف نہ کر سکے۔

• ** ہر پروڈکشن کوبرنیٹس کو تبدیل کریں۔ StorageClass سے reclaimPolicy: Delete کو reclaimPolicy: Retain**: بطور ڈیفالٹ، بلٹ ان کلاؤڈ اسٹوریج کلاسز (gp2، gp3، standard-rwo) پہلے سے طے شدہ reclaimPolicy: Delete، یعنی پی وی سی کو حذف کرنے سے کلاؤڈ ڈسک تباہ ہوجاتی ہے۔ بنائیں a StorageClass کے ساتھ reclaimPolicy: Retain (یا موجودہ PVs کے ساتھ پیچ کریں۔ kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') لہذا PVC یا Namespace کو حذف کرنے سے کبھی بھی بنیادی بلاک والیوم حذف نہیں ہوتا ہے۔
• CSI سنیپ شاٹس کے ساتھ AWS EBS Recycle Bin / GCP سنیپ شاٹ شیڈولز / Velero کو فعال کریں: AWS EBS Recycle Bin کو فعال کرنا کسی بھی حذف شدہ EBS والیوم کو 7 سے 30 دنوں تک برقرار رکھتا ہے چاہے CSI ڈرائیور کال کرے۔ DeleteVolume.
• ** کبھی استعمال نہ کریں۔ docker system prune --volumes خودکار کلین اپ اسکرپٹس یا CI/CD رنرز** میں: اگر کوئی پروڈکشن ڈیٹا بیس کنٹینر مختصر طور پر کریش ہو جائے (Exited (1)) عین وقت پر ایک کرون جاب چلتا ہے۔ docker system prune -a --volumes -f، Docker اپنی گمنام جلدوں کو "غیر استعمال شدہ" سمجھتا ہے اور انہیں مستقل طور پر حذف کر دیتا ہے۔ پٹی --volumes تمام کلین اپ اسکرپٹس سے۔
• ** واضح ہوسٹ بائنڈ ماونٹس کا استعمال کریں (/srv/prod_data/postgres:/var/lib/postgresql/data) یا اسٹیٹفول پروڈکشن ورک بوجھ کے لیے بیرونی منظم ڈیٹا بیس**: برعکس /var/lib/docker/volumes/، باہر بائنڈ ماؤنٹ ڈائریکٹریز کی میزبانی کریں۔ /var/lib/docker/ کبھی نہیں چھوا docker compose down -v، docker volume rm، یا docker system prune --volumes.

علاقائی ہنگامی نمبر اور ایجنسی پروٹوکول¶

جب کوئی کنٹینر یا Kubernetes اسٹوریج ڈیلیٹ کرنے سے ہسپتال کے طبی آپریشنز، پبلک سیفٹی ڈسپیچ، یا ریگولیٹڈ ذاتی ڈیٹا پر اثر پڑتا ہے، تو فوری طور پر بڑھیں:

• ریاستہائے متحدہ اور کینیڈا: ڈائل کریں 911 اگر کنٹینر کلسٹر کی ناکامی کلینیکل مریض کی نگرانی، EHR سسٹم، یا ایمرجنسی ڈسپیچ کو غیر فعال کر دیتی ہے۔ نقصان دہ کنٹینر انفراسٹرکچر صاف کرنے یا سائبر واقعات کی اطلاع CISA (1-844-Say-CISA / cisa.gov/report) یا کینیڈین سینٹر فار سائبر سیکیورٹی (1-833-CYBER-88)
• برطانیہ: ڈائل کریں999 زندگی کو لاحق خطرات یا NHS کے اہم انفراسٹرکچر کے لیے۔ UK GDPR کے تحت، قابل بازیافت بیک اپ کے بغیر ذاتی ڈیٹا کی مستقل تباہی یا دستیابی کے نقصان کے لیے ICO کو 72 گھنٹے کی خلاف ورزی کی اطلاع کا جائزہ لینے کی ضرورت ہے۔0303 123 1113)
• یورپی یونین: ڈائل کریں 112 یورپی یونین کے تمام رکن ممالک میں۔ NIS2 ڈائریکٹیو کے تحت اداروں کو سروس کی شدید بندش کے 24 گھنٹوں کے اندر اپنے قومی CSIRT کو ابتدائی وارننگ جمع کرانی چاہیے، اور مستقل ذاتی ڈیٹا کے نقصان سے GDPR آرٹیکل 33 رپورٹنگ 72 گھنٹوں کے اندر اندر ہوتی ہے۔
• آسٹریلیا اور نیوزی لینڈ: ڈائل کریں 000 آسٹریلیا میں یا 111 نیوزی لینڈ میں؛ بنیادی ڈھانچے کے اہم واقعات کی رپورٹ ACSC (1300 CYBER1)
• انڈیا اور ایشیا پیسیفک: ڈائل کریں 112 ہندوستان میں ہنگامی ردعمل کے لیے؛ کلاؤڈ یا کنٹینر سیکیورٹی کے واقعات کی اطلاع CERT-In ( کو دیںincident@cert-in.org.in) لازمی 6 گھنٹے کی ونڈو کے اندر۔

اکثر پوچھے گئے سوالات¶

کرتا ہے۔ docker compose down -v ہوسٹ بائنڈ ماونٹس کو حذف کریں (./data:/var/lib/mysql) یا صرف نام اور گمنام ڈوکر والیوم؟¶

`docker compose down -v` میں صرف نامزد جلدوں کو حذف کرتا ہے۔ `volumes:` کا سیکشن `docker-compose.yml` اور گمنام جلدیں کنٹینرز سے منسلک ہیں۔; یہ کبھی نہیں ہوسٹ بائنڈ ماؤنٹ کے اندر فائلوں کو حذف کرتا ہے (جیسے `- /opt/mysql_data:/var/lib/mysql` یا `- ./postgres_data:/var/lib/postgresql/data`)۔ اگر آپ کی کمپوز فائل نے شروع ہونے والے ہوسٹ پاتھ کا استعمال کیا ہے۔ `/` یا `./`اس فولڈر کو ابھی میزبان پر چیک کریں: آپ کی فائلیں اب بھی 100 فیصد برقرار ہیں۔

کیوں کیا docker system prune --volumes اپنے ڈیٹا بیس والیوم کو حذف کریں جب میں نے ماحولیاتی متغیر کو اپ ڈیٹ کرنے کے لیے کنٹینر کو صرف 2 منٹ کے لیے روکا تھا؟¶

کے درمیان فرق کے لیے احتیاط سے انتظار کریں۔ `docker stop` اور `docker rm`: اگر ایک کنٹینر محض ہے۔ `Stopped / Exited` (میں نظر آتا ہے۔ `docker ps -a`) `docker system prune --volumes` کرتا ہے نہیں اس کے حجم کو حذف کریں کیونکہ روکا ہوا کنٹینر اب بھی ان کا حوالہ دیتا ہے۔ تاہم، اگر آپ بھاگ گئے `docker rm ` (نئے جھنڈوں کے ساتھ کنٹینر کو دوبارہ بنانے کے لیے) یا اگر آپ گزر گئے ہیں۔ `docker system prune -a --volumes` (جو پہلے تمام رکے ہوئے کنٹینرز کو حذف کرتا ہے اور پھر تمام جلدوں کو حذف کر دیتا ہے جو اب کسی کنٹینر کے ساتھ منسلک نہیں ہے)، والیوم ملی سیکنڈ میں "لٹکتا ہوا" ہو گیا جب روکا ہوا کنٹینر ہٹا دیا گیا اور اس کے فوراً بعد اسے صاف کر دیا گیا۔

کیا میں میک پر ڈوکر ڈیسک ٹاپ کے اندر حذف شدہ ڈوکر والیوم کو بازیافت کرسکتا ہوں (Apple Silicon / Intel) یا ونڈوز (WSL2)؟¶

ہاں، اگر آپ Docker ڈیسک ٹاپ کو فوری طور پر چھوڑ دیتے ہیں تو ورچوئل مشین چلنا بند کر دیتی ہے۔ `fstrim` ورچوئل ڈسک کے خلاف۔ macOS پر، Docker تمام لینکس والیوم کو اندر اسٹور کرتا ہے۔ `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; ونڈوز WSL2 پر، اندر `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. اس کو کاپی کریں۔ `.raw` یا `.vhdx` فائل کو فوری طور پر کسی بیرونی SSD سے منسلک کریں، اسے لینکس میں صرف پڑھنے کے لیے منسلک کریں (استعمال کرتے ہوئے `losetup -Pr` کے لیے `.raw` یا `qemu-nbd -r` کے لیے `.vhdx`)، اور چلائیں `ext4magic` یا `PhotoRec` مجازی کے خلاف `ext4` اندر تقسیم.

اگر میں نے Kubernetes StatefulSet کے ساتھ حذف کر دیا تو کیا ہوگا؟ kubectl delete statefulset postgres? کیا اس سے میرے پی وی سی بھی حذف ہو گئے؟¶

نہیں. Kubernetes میں بطور ڈیفالٹ (جب تک کہ `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` واضح طور پر Kubernetes 1.27+ پر ترتیب دیا گیا تھا)، چل رہا ہے۔ `kubectl delete statefulset` اسٹیٹفل سیٹ کنٹرولر اور اس کے پوڈز کو حذف کرتا ہے، سب چھوڑ کر `PersistentVolumeClaims` (`data-postgres-0`، `data-postgres-1`) اور ان کا بنیادی ڈیٹا 100 فیصد برقرار ہے۔. بس دوبارہ اپلائی کریں۔ `StatefulSet` YAML اسی نام کے ساتھ ظاہر ہوتا ہے اور `volumeClaimTemplates`، اور نئے Pods خود بخود موجودہ سے دوبارہ منسلک ہو جائیں گے۔ `data-postgres-0` پی وی سی

میں ڈوکر کے اندر فائلوں تک کیسے رسائی حاصل کرسکتا ہوں۔ overlay2 ڈائریکٹری جب کنٹینر شروع ہونے سے انکار کرتا ہے (CrashLoopBackOff / Exited (1))؟¶

کریش ہونے والے کنٹینر کو حذف نہ کریں۔ جب تک روکا ہوا کنٹینر اب بھی موجود ہے۔ `docker ps -a`، اس کی قابل تحریر پرت اور والیوم ماونٹس ڈسک پر مکمل طور پر برقرار ہیں۔ آپ یا تو فائلوں کو روکے ہوئے کنٹینر سے براہ راست کاپی کر سکتے ہیں۔ `docker cp :/var/lib/postgresql/data /root/rescued_data`، یا اس کا صحیح میزبان تلاش کریں۔ `overlay2` دوڑ کر راستہ `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` اور اس ڈائرکٹری کو براہ راست پڑھنا `root`.

کیا ہوگا اگر کسی نے کبرنیٹس کو حذف کر دیا۔ Namespace (kubectl delete ns prod) اور تمام PVCs تھے۔ reclaimPolicy: Delete AWS EBS یا GCP پر؟¶

اگر کلاؤڈ CSI ڈرائیور (`ebs.csi.aws.com` یا `pd.csi.storage.gke.io`) پہلے ہی پھانسی دے دی گئی ہے۔ `DeleteVolume` کیونکہ `reclaimPolicy` تھا `Delete`, تین کلاؤڈ لیول سیفٹی نیٹ کو فوری طور پر چیک کریں: (1) AWS EC2 کنسول میں **EBS والیوم کے لیے AWS Recycle Bin** چیک کریں (اگر اکاؤنٹ/ٹیگز پر برقرار رکھنے کا کوئی اصول فعال تھا، حذف شدہ EBS والیوم Recycle Bin میں بیٹھتا ہے اور 1 کلک میں بحال کیا جا سکتا ہے)؛ (2) تازہ ترین خودکار والیوم اسنیپ شاٹ کے لیے **AWS بیک اپ/DLM/GCP سنیپ شاٹ شیڈولز** چیک کریں۔ اور (3) چیک کریں کہ آیا آپ کا ڈیٹا بیس WAL/binlogs کو سٹریم کر رہا تھا (`WAL-G`، `pgBackRest`، `Litestream`ایک S3/GCS بالٹی تک۔

متعلقہ گائیڈز¶

• سرور ڈسک 100% مکمل (0 بائٹس مفت): ڈیٹا بیس WAL لاگ بلوٹ، کرپٹڈ بی ٹری، اور صفر اسپیس ریکوری
• لینکس، میک او ایس، یا ونڈوز پر حادثاتی rm -rf یا Shift+Delete: فوری طور پر صرف پڑھنے کے لئے دوبارہ ماؤنٹ اور انوڈ نقش کاری
• ورچوئل مشین VMDK، VHDX، اور qcow2 سنیپ شاٹ چین بدعنوانی اور ہائپر وائزر ریسکیو
• AWS کلیدوں، .env فائل، یا عوامی GitHub ریپو کے لئے نجی SSH کلید کا حادثاتی گٹ کمٹ
• ویب ہوسٹنگ کا بحران، ہجرت، اور بیک اپ کی بحالی
• کمپیوٹر بیک اپ، 3-2-1 حکمت عملی، اور ڈیزاسٹر ریکوری
• ملک کے لحاظ سے ہنگامی نمبر

ذرائع اور سرکاری رہنمائی¶

• Kubernetes سرکاری دستاویزات (kubernetes.io / کلاؤڈ مقامی کمپیوٹنگ فاؤنڈیشن: استعمال کے تحفظ میں ذخیرہ آبجیکٹ (kubernetes.io/pvc-protection فائنلائزر)، پرسسٹنٹ والیوم کا دوبارہ دعوی کرنا (Retain بمقابلہ Delete)، اور آپریٹنگ etcd کلسٹرز برائے Kubernetes (etcdctl snapshot restore)
• Docker Inc. (docs.docker.com): ڈاکر میں ڈیٹا کا نظم کریں: والیوم، بائنڈ ماؤنٹس، overlay2 سٹوریج ڈرائیور آرکیٹیکچر، اور پرون حوالہ۔
• لینکس کرنل آرگنائزیشن (kernel.org):دی /proc فائل سسٹم (procfs فائل ڈسکرپٹر ریکوری کے ذریعے کھولیں۔ /proc/<pid>/fd/) اور Ext4 جرنل کی تفصیلات۔
• ext4magic پروجیکٹ دستاویزیext4magic.sourceforge.net): Forensic Inode اور Ext3/Ext4 فائل سسٹمز پر جرنل ٹرانزیکشن ریکوری۔
• نیشنل انسٹی ٹیوٹ آف اسٹینڈرڈز اینڈ ٹیکنالوجی (NIST) (ریاستہائے متحدہ): خصوصی اشاعت 800-190: ایپلیکیشن کنٹینر سیکیورٹی گائیڈ اور واقعہ کی بازیابی۔