डॉकर किंवा कुबर्नेट्स प्रोडक्शन व्हॉल्यूम हटवले: बचाव करत आहे 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: रीड-ओन्ली रिमाउंट आणि इनोड कोरीविंग आणि आभासी मशीन VMDK, VHDX, आणि qcow2 स्नॅपशॉट चेन भ्रष्टाचार आणि हायपरवाइजर बचाव. या उत्पादन आउटेजमुळे रुग्णालयातील रुग्णांची काळजी, आपत्कालीन प्रेषण किंवा सार्वजनिक उपयोगिता सुरक्षा प्रणालींवर परिणाम होत असल्यास, तुमच्या स्थानिक आपत्कालीन क्रमांकावर कॉल करा (911 युनायटेड स्टेट्स आणि कॅनडा मध्ये, 112 युरोपियन युनियन ओलांडून, 999 युनायटेड किंगडममध्ये) किंवा आमची निर्देशिका तपासा आपत्कालीन क्रमांक.

आता हे करा¶

1. ** धावू नका docker compose up -d, systemctl restart docker, किंवा Kubernetes पॉड पुन्हा तैनात करा**: कंटेनर पुन्हा तयार करणे किंवा डॉकर डिमन रीस्टार्ट केल्याने नवीन मेगाबाइट्स लिहितात overlay2 मेटाडेटा, कंटेनर JSON लॉग आणि नव्याने आरंभ केलेल्या रिकाम्या डेटाबेस फाइल्स (initdb) थेट अचूक ext4 किंवा XFS ब्लॉक जेथे तुमचा हटवलेला व्हॉल्यूम सेकंदांपूर्वी बसला होता.
2. ** कंटेनर प्रक्रिया असल्यास 5 सेकंदात तपासा (postgres, mysqld, redis-server, node, python) अजूनही स्मृतीमध्ये चालू आहे (ps aux आणि sudo lsof +L1);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. ** जर तुम्ही कुबर्नेट्सवर असाल तर (kubectl delete pvc किंवा kubectl delete namespace), पर्सिस्टंट व्हॉल्यूम तपासा (PV) ReclaimPolicy (kubectl get pv) लगेच**:
5. जर द PV होते persistentVolumeReclaimPolicy: Retain, तुमचा डेटा हटलेला नाही: द PV फक्त हलविले Released स्थिती आणि तुमची क्लाउड डिस्क (EBS, Azure Disk, Ceph RBD, NFS) 100 टक्के शाबूत आहे.
6. जरी kubectl delete pvc ** मध्ये अडकले आहेTerminating**, कुबेरनेट्स फायनलाइजर्स (kubernetes.io/pvc-protection) CSI ड्रायव्हरला अंतर्निहित स्टोरेज हटवण्यापासून ब्लॉक करा जोपर्यंत कोणताही Pod अजूनही PVC चा संदर्भ देत नाही. जोपर्यंत तुम्ही चालू पॉडमधून डेटा कॉपी करत नाही तोपर्यंत पॉड हटवू नका.
7. ** अंतर्निहित ब्लॉक विभाजनाची प्रतिमा (dd / ddrescue SSH वर) बाह्य डिस्कवर किंवा चालू करण्यापूर्वी स्वतंत्र क्लाउड व्हॉल्यूम ext4magic, extundelete, किंवा PhotoRec**: ज्या डिस्क विभाजनातून तुम्ही पुनर्प्राप्त करत आहात त्याच डिस्क विभाजनावर आउटपुट फाइल्स लिहिणारे फाईल कार्व्हर्स कधीही चालवू नका. /var/lib/docker/volumes.
8. कुबर्नेट्स क्लस्टर स्थिती दूषित किंवा चुकून पुसलेल्या (kubectl delete crd / namespace), थांबा kube-apiserver आणि तुमचे नवीनतम पुनर्संचयित करा etcd स्नॅपशॉट (etcdctl snapshot restore): जर क्लस्टर स्थितीत असेल etcd अंतर्निहित क्लाउड स्टोरेज व्हॉल्यूम अजूनही अस्तित्वात असताना, पुनर्संचयित करताना पुसले गेले etcd सर्व पुनर्प्राप्त करते PV, PVC, Secret, आणि ConfigMap एकाच वेळी वस्तू.

निर्णय वृक्ष: हटवलेले डॉकर व्हॉल्यूम, overlay2 स्तर, किंवा कुबर्नेट्स पीव्हीसी ट्रायज¶

कंटेनर प्रक्रिया अद्याप जिवंत आहे की नाही, व्हॉल्यूम स्थानिक डिस्क किंवा क्लाउड CSI स्टोरेजद्वारे समर्थित आहे की नाही आणि कोणती फाइल सिस्टम होस्ट करते यावर आधारित सर्वात जलद शून्य-नुकसान पुनर्प्राप्ती मार्ग निवडण्यासाठी हा फ्लोचार्ट वापरा /var/lib/docker:

flowchart TD
    Start["डॉकर किंवा कुबर्नेट्स डिलीट कमांडनंतर उत्पादन डेटा गहाळ आहे"] --> WhichEnv{"कोणत्या प्लॅटफॉर्म आणि कमांडमुळे नुकसान झाले?"}

    WhichEnv -->|"डॉकर: कंटेनर अजूनही चालू आहे (व्हॉल्यूम/कंटेनरच्या आत फायली अनलिंक केल्या आहेत)"| ProcRescue["sudo lsof +L1 आणि /proc/PID/fd/N किंवा /proc/PID/root/ द्वारे अनलिंक केलेल्या फाइल डिस्क्रिप्टर उघडा."]

    WhichEnv -->|"डॉकर: कंटेनर थांबवले आणि व्हॉल्यूम हटवले (कंपोज डाउन -v / प्रुन --वॉल्यूम)"| StopDocker["ताबडतोब चालवा: sudo systemctl stop docker.socket docker कंटेनर"]

    WhichEnv -->|"Kubernetes: kubectl हटवा pvc / pv / statefulset / namespace"| K8sCheck{"पॉड अजूनही चालू आहे किंवा पीव्हीसी संपुष्टात अडकला आहे?"}

    K8sCheck -->|"होय: पॉड स्टिल रनिंग (फायनालायझर ब्लॉकिंग सीएसआय डिलीट)"| K8sExec["पॉड हटवू नका -> kubectl exec/pg_dump/tar stdout वर स्थानिक डिस्कवर ताबडतोब चालवा"]
    K8sCheck -->|"नाही: पॉड गॉन -> कुबेक्टल गेट पीव्ही तपासा"| ReclaimCheck{"पीव्ही रिक्लेम पॉलिसी काय होती?"}

    ReclaimCheck -->|"राखून ठेवा (पीव्ही स्थिती = रिलीज)"| ClearClaimRef["100% डेटा अखंड -> spec.claimRef.uid काढण्यासाठी PV संपादित करा -> नवीन PVC वर पुन्हा-बाइंड करा"]
    ReclaimCheck -->|"हटवा (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"क्लाउड CSI व्हॉल्यूम किंवा स्थानिक होस्ट डिस्क?"}

    CloudOrLocal -->|"क्लाउड CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["क्लाउड कन्सोल रीसायकल बिन / स्वयंचलित EBS स्नॅपशॉट्स / Ceph RBD कचरा (rbd कचरा ls) तपासा"]
    CloudOrLocal -->|"स्थानिक नोड डिस्क (स्थानिक-पथ / होस्टपथ)"| StopDocker

    StopDocker --> RemountRO["रिमाउंट होस्ट विभाजन केवळ-वाचनीय (mount -o remount,ro) किंवा SSH वर स्ट्रीम ब्लॉक प्रतिमा"]
    RemountRO --> HostFS{"काय फाइलसिस्टम होस्ट /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["debugfs / ext4magic जर्नल इनोड ट्रान्झॅक्शन रोलबॅक वापरा (-एक टाइमस्टॅम्प)"]
    HostFS -->|"XFS/Btrfs"| CarveRec["SQLite, Postgres Heap, किंवा InnoDB .ibd साठी Btrfs रूट्स / 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() म्हणतात. ओपन फाइल डिस्क्रिप्टर (FD) ते इनोड ते बंद करते किंवा बाहेर पडते.

पायरी 1: होस्ट प्रोसेस आयडी शोधा (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) कंटेनर एफडी बंद करण्यापूर्वी¶

जर 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: Linux होस्ट फाइलसिस्टम 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 रूट वर आहे / विभाजन (/), कर्नल 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 / extent ट्री रूट) लाईव्ह इनोड टेबलमध्ये. तथापि, 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 - उदा., Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana)**: प्रत्येक 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: कुबर्नेट्स पीव्हीसी, पीव्ही, आणि etcd स्नॅपशॉट आपत्कालीन पुनर्प्राप्ती¶

कुबर्नेट्समध्ये (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), चुकून Persistent VolumeClaim हटवणे (kubectl delete pvc), एक स्टेटफुल सेट, किंवा संपूर्ण नेमस्पेस (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 मध्ये Persistent Volume दाखवते 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: पुसलेली कुबर्नेट्स क्लस्टर स्थिती an पासून पुनर्संचयित करणे etcd स्नॅपशॉट (etcdctl snapshot restore)¶

कोणी धावले तर काय kubectl delete namespace prod किंवा helm uninstall आणि 200 कुबर्नेट्स मॅनिफेस्ट, सिक्रेट्स, कॉन्फिगमॅप्स आणि पीव्ही व्याख्या पुसून टाकल्या. 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: अपघाती हटविण्याविरूद्ध डॉकर आणि कुबर्नेट्स व्हॉल्यूम हार्डनिंग¶

एकदा तुमचा उत्पादन डेटाबेस पुनर्संचयित झाल्यानंतर, या चार आर्किटेक्चरल रेलिंगची अंमलबजावणी करा जेणेकरून एकल CLI टायपो पुन्हा कधीही थेट व्हॉल्यूम हटवू शकत नाही:

• कुबर्नेट्सचे प्रत्येक उत्पादन बदला StorageClass पासून reclaimPolicy: Delete करण्यासाठी reclaimPolicy: Retain: डीफॉल्टनुसार, अंगभूत क्लाउड स्टोरेज क्लासेस (gp2, gp3, standard-rwo) वर डीफॉल्ट reclaimPolicy: Delete, म्हणजे पीव्हीसी हटवणे क्लाउड डिस्क नष्ट करते. ए तयार करा StorageClass सह reclaimPolicy: Retain (किंवा विद्यमान पीव्ही सह पॅच करा kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') त्यामुळे PVC किंवा नेमस्पेस हटवण्याने कधीही अंतर्निहित ब्लॉक व्हॉल्यूम हटत नाही.
• CSI स्नॅपशॉटसह AWS EBS रीसायकल बिन / GCP स्नॅपशॉट शेड्यूल / Velero सक्षम करा: AWS EBS रीसायकल बिन सक्षम केल्याने CSI ड्रायव्हरने कॉल केला तरीही हटवलेला कोणताही EBS व्हॉल्यूम 7 ते 30 दिवसांपर्यंत टिकवून ठेवतो. DeleteVolume.
• ** कधीही वापरू नका docker system prune --volumes स्वयंचलित क्लीनअप स्क्रिप्ट्स किंवा सीआय/सीडी रनर्स**: जर उत्पादन डेटाबेस कंटेनर थोडक्यात क्रॅश झाला (Exited (1)) नेमक्या क्षणी क्रॉन जॉब चालतो docker system prune -a --volumes -f, डॉकर त्याचे अनामित खंड "न वापरलेले" मानतो आणि ते कायमचे हटवतो. पट्टी --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.

प्रादेशिक आणीबाणी क्रमांक आणि एजन्सी प्रोटोकॉल¶

जेव्हा कंटेनर किंवा कुबर्नेट्स स्टोरेज हटवण्याचा परिणाम हॉस्पिटलच्या क्लिनिकल ऑपरेशन्स, सार्वजनिक सुरक्षा पाठवण्यावर किंवा नियमित वैयक्तिक डेटावर होतो, तेव्हा त्वरित वाढवा:

• युनायटेड स्टेट्स आणि कॅनडा: डायल करा 911 कंटेनर क्लस्टर अयशस्वी झाल्यास क्लिनिकल पेशंट मॉनिटरिंग, EHR सिस्टम किंवा आणीबाणी डिस्पॅच अक्षम करते. दुर्भावनापूर्ण कंटेनर इन्फ्रास्ट्रक्चर वाइप किंवा सायबर घटनांची तक्रार CISA (1-844-Say-CISA / cisa.gov/report) किंवा कॅनेडियन सेंटर फॉर सायबर सिक्युरिटी (1-833-CYBER-88).
• युनायटेड किंगडम: डायल करा 999 जीवाला धोका किंवा गंभीर NHS पायाभूत सुविधांसाठी. UK GDPR अंतर्गत, पुनर्प्राप्त करण्यायोग्य बॅकअपशिवाय वैयक्तिक डेटाची उपलब्धता कायमस्वरूपी नष्ट होणे किंवा गमावणे यासाठी ICO (0303 123 1113).
• युरोपियन युनियन: डायल करा 112 सर्व EU सदस्य राज्यांमध्ये. NIS2 निर्देश अंतर्गत असलेल्या संस्थांनी त्यांच्या राष्ट्रीय CSIRT ला सेवा बंद होण्याच्या 24 तासांच्या आत प्रारंभिक चेतावणी सबमिट करणे आवश्यक आहे आणि कायमस्वरूपी वैयक्तिक डेटा गमावल्यास 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)?¶

होय, तुम्ही डॉकर डेस्कटॉप ताबडतोब सोडल्यास व्हर्च्युअल मशीन चालणे थांबेल `fstrim` आभासी डिस्क विरुद्ध. macOS वर, डॉकर सर्व लिनक्स व्हॉल्यूम आत साठवतो `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; Windows 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? त्यामुळे माझे PVC देखील हटले का?¶

नाही. Kubernetes मध्ये डीफॉल्टनुसार (जोपर्यंत `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` Kubernetes 1.27+ वर स्पष्टपणे कॉन्फिगर केले होते), चालू आहे `kubectl delete statefulset` स्टेटफुलसेट कंट्रोलर आणि त्याचे पॉड हटवते, सर्व सोडून `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) आणि त्यांचा अंतर्निहित डेटा 100 टक्के अबाधित आहे. फक्त तुमचा पुन्हा अर्ज करा `StatefulSet` YAML त्याच नावाने मॅनिफेस्ट आणि `volumeClaimTemplates`, आणि नवीन पॉड्स आपोआप विद्यमान शी पुन्हा संलग्न होतील `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) आणि सर्व PVC होते reclaimPolicy: Delete AWS EBS किंवा GCP वर?¶

जर क्लाउड CSI ड्रायव्हर (`ebs.csi.aws.com` किंवा `pd.csi.storage.gke.io`) आधीच अंमलात आणले आहे `DeleteVolume` कारण `reclaimPolicy` होते `Delete`, तीन क्लाउड-स्तरीय सुरक्षा जाळ्या ताबडतोब तपासा: (1) AWS EC2 कन्सोलमध्ये **EBS व्हॉल्यूमसाठी AWS रीसायकल बिन** तपासा (जर खाते/टॅगवर एक धारणा नियम सक्रिय असेल तर, हटवलेला EBS व्हॉल्यूम रीसायकल बिनमध्ये बसतो आणि 1 क्लिकमध्ये पुनर्संचयित केला जाऊ शकतो); (२) सर्वात अलीकडील स्वयंचलित व्हॉल्यूम स्नॅपशॉटसाठी **AWS बॅकअप / DLM / GCP स्नॅपशॉट शेड्यूल** तपासा; आणि (३) तुमचा डेटाबेस WAL/binlogs प्रवाहित करत आहे का ते तपासा (`WAL-G`, `pgBackRest`, `Litestream`) S3/GCS बकेटला.

संबंधित मार्गदर्शक¶

• सर्व्हर डिस्क 100% भरलेली (0 बाइट्स विनामूल्य): डेटाबेस WAL लॉग ब्लोट, दूषित बी-ट्री, आणि शून्य-स्पेस पुनर्प्राप्ती
• Linux, macOS किंवा Windows वर अपघाती rm -rf किंवा Shift+Delete: तात्काळ वाचनीय रिमाउंट आणि इनोड कोरीव
• व्हर्च्युअल मशीन VMDK, VHDX, आणि qcow2 स्नॅपशॉट चेन भ्रष्टाचार आणि हायपरवाइजर बचाव
• AWS की, .env फाइल, किंवा सार्वजनिक GitHub रेपोसाठी खाजगी SSH कीची अपघाती Git कमिट
• वेब होस्टिंग संकट, स्थलांतर आणि बॅकअप पुनर्संचयित
• संगणक बॅकअप, 3-2-1 धोरण आणि आपत्ती पुनर्प्राप्ती
• देशानुसार आणीबाणी क्रमांक

स्रोत आणि अधिकृत मार्गदर्शन¶

• कुबर्नेट्स अधिकृत दस्तऐवजीकरण (kubernetes.io / क्लाउड नेटिव्ह कॉम्प्युटिंग फाउंडेशन): स्टोरेज ऑब्जेक्ट इन यूज प्रोटेक्शन (kubernetes.io/pvc-protection फायनलाइजर्स), पर्सिस्टंट व्हॉल्यूम्सचा पुन्हा दावा करणे (Retain वि. Delete), आणि ऑपरेटिंग etcd कुबर्नेट्ससाठी क्लस्टर्स (etcdctl snapshot restore).
• डॉकर इंक. (docs.docker.com): डॉकरमध्ये डेटा व्यवस्थापित करा: व्हॉल्यूम, बाइंड माउंट्स, overlay2 स्टोरेज ड्रायव्हर आर्किटेक्चर, आणि प्रुन संदर्भ.
• लिनक्स कर्नल संघटना (kernel.org): द /proc फाइलसिस्टम (procfs द्वारे फाइल डिस्क्रिप्टर रिकव्हरी उघडा /proc/<pid>/fd/) आणि Ext4 जर्नल तपशील.
• ext4magic प्रकल्प दस्तऐवजीकरण (ext4magic.sourceforge.net): Forensic Inode आणि Ext3/Ext4 फाइलसिस्टम्सवर जर्नल ट्रान्झॅक्शन रिकव्हरी.
• राष्ट्रीय मानक आणि तंत्रज्ञान संस्था (NIST) (युनायटेड स्टेट्स): विशेष प्रकाशन 800-190: अनुप्रयोग कंटेनर सुरक्षा मार्गदर्शक आणि घटना पुनर्प्राप्ती.