Docker- of Kubernetes-produksievolume geskrap: redding docker system prune --volumes, overlay2 Inodes, en etcd Foto's¶

Hardloop docker compose down -v, docker system prune -a --volumes, docker volume rm, of kubectl delete pvc op die verkeerde terminaaloortjie in produksie is een van die vinnigste maniere om 'n lewendige PostgreSQL-, MySQL-, MariaDB-, Redis-, MongoDB- of SQLite-databasisvolume uit te vee. Anders as wolk virtuele masjien snapshots wat na 'n 7-dae asblik skuif, Docker se plaaslike volume bestuurder (/var/lib/docker/volumes/<name>/_data) en Kubernetes local-path / hostPath voorsieners reik onmiddellik standaard POSIX uit unlink() en rmdir() oproepe direk teen die onderliggende Linux-gasheerlêerstelsel (ext4, XFS, of Btrfs). Elke skryf wat op daardie Linux-gasheer plaasvind nadat die opdrag voltooi is, kan die vrygestelde databasisblokke op skyf oorskryf. As jou bedienerskyf tot 100 persent gevul is (0 bytes free) voordat iemand gehardloop het docker system prune --volumes in paniek, raadpleeg bedienerskyf 100% vol, databasis-WAL-logopblaas en nulspasie-herwinning; vir kaalmetaal Linux-lêerskrapings buite houers, sien toevallige rm -rf of Shift-Delete op ext4, XFS, APFS en NTFS: leesalleen hermonteer en inodesny en virtuele masjien VMDK, VHDX en qcow2 momentopname ketting korrupsie en hipervisor redding. As hierdie produksieonderbreking 'n impak het op hospitaalpasiëntversorging, noodversending of veiligheidstelsels van openbare nutsdienste, skakel jou plaaslike noodnommer (911 in die Verenigde State en Kanada, 112 regoor die Europese Unie, 999 in die Verenigde Koninkryk) of kyk na ons gids van noodnommers.

Doen dit nou¶

1. ** MOENIE hardloop nie docker compose up -d, systemctl restart docker, of herontplooi die Kubernetes-peul**: Deur die houer te herskep of die Docker-daemon te herbegin, skryf megagrepe nuwe overlay2 metadata, houer JSON-logboeke en vars geïnisialiseerde leë databasislêers (initdb) direk oor die presiese ext4 of XFS blokke waar jou geskrap volume sekondes gelede gesit het.
2. Kyk in 5 sekondes as die houerproses (postgres, mysqld, redis-server, node, python) loop steeds in geheue (ps aux en sudo lsof +L1): As iemand lêers binne 'n gemonteerde volume uitgevee het of 'n anonieme volume ontkoppel het terwyl die houer nog loop, hou die Linux-kern 100 persent van die ongekoppelde databasislêers lewendig op skyf solank die houer se gasheerproses-ID (PID) hou 'n oop lêerbeskrywing (FD). Jy kan daardie lêers direk uit kopieer /proc/<PID>/fd/ of /proc/<PID>/root/ met geen dataverlies voordat die houer stop nie.
3. As die houer reeds gestop is en die volume is uitgevee (docker compose down -v of docker system prune --volumes), vries gasheerskyf skryf dadelik: Stop die Docker-demon (sudo systemctl stop docker.socket docker.service containerd) sodat agtergrondhouers en gesondheidskontroles ophou om logs in te skryf /var/lib/docker, dan óf herlaai /var/lib/docker (of die wortel / partisie) leesalleen (sudo mount -o remount,ro /) of neem 'n onmiddellike blokvlak wolkvolume momentopname (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) voordat jy aan enigiets raak.
4. As jy op Kubernetes is (kubectl delete pvc of kubectl delete namespace), kyk na die PersistentVolume (PV) ReclaimPolicy (kubectl get pv) onmiddellik:
5. As die PV gehad het persistentVolumeReclaimPolicy: Retain, jou data is nie uitgevee nie: die PV eenvoudig verskuif na Released status en jou wolkskyf (EBS, Azure Disk, Ceph RBD, NFS) is 100 persent ongeskonde.
6. Selfs al kubectl delete pvc sit vas in Terminating, Kubernetes Finaliseerders (kubernetes.io/pvc-protection) blokkeer die CSI-bestuurder om die onderliggende berging uit te vee, solank enige Pod nog na daardie PVC verwys. Moenie die Pod uitvee voordat jy die data uit die lopende Pod kopieer nie.
7. Beeld die onderliggende blokpartisie (dd / ddrescue oor SSH) na 'n eksterne skyf of aparte wolkvolume voordat dit hardloop ext4magic, extundelete, of PhotoRec: Moet nooit lêersnyers gebruik wat uitvoerlêers op dieselfde skyfpartisie skryf waarvandaan jy herstel nie /var/lib/docker/volumes.
8. Vir korrupte of per ongeluk uitgevee Kubernetes-klusterstatus (kubectl delete crd / namespace), stop kube-apiserver en herstel jou nuutste etcd momentopname (etcdctl snapshot restore): As die groep in etcd is uitgevee terwyl die onderliggende wolkbergingsvolumes nog bestaan, besig om te herstel etcd herstel alles PV, PVC, Secret, en ConfigMap voorwerpe gelyktydig.

Besluitboom: geskrap Docker-volume, overlay2 laag, of Kubernetes PVC triage¶

Gebruik hierdie vloeidiagram om die vinnigste nul-verlies-herstelpad te kies, gebaseer op of die houerproses nog lewendig is, of die volume deur plaaslike skyf of wolk CSI-berging gerugsteun is, en watter lêerstelsel gasheer is /var/lib/docker:

flowchart TD
    Start["Produksiedata ontbreek na Docker of Kubernetes Delete Command"] --> WhichEnv{"Watter platform en opdrag het die verlies veroorsaak?"}

    WhichEnv -->|"Docker: Houer loop steeds (lêers ontkoppel binne volume/houer)"| ProcRescue["Red oopgekoppelde lêerbeskrywings via sudo lsof +L1 en /proc/PID/fd/N of /proc/PID/root/"]

    WhichEnv -->|"Docker: Houer gestop en volume verwyder (compose down -v / snoei --volumes)"| StopDocker["Onmiddellik hardloop: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl verwyder pvc / pv / statefulset / naamruimte"| K8sCheck{"Loop die peul nog OF sit PVC vas aan die einde?"}

    K8sCheck -->|"Ja: Peul loop steeds (Finalizer blokkeer CSI Delete)"| K8sExec["MOENIE Pod uitvee nie -> Begin kubectl exec / pg_dump / tar onmiddellik oor stdout na plaaslike skyf"]
    K8sCheck -->|"No: Pod Gone -> Check kubectl get pv"| ReclaimCheck{"Wat was die PV-herwinningsbeleid?"}

    ReclaimCheck -->|"Behou (PV-status = Vrygestel)"| ClearClaimRef["100% data ongeskonde -> Wysig PV om spec.claimRef.uid te verwyder -> Herbind aan nuwe PVC"]
    ReclaimCheck -->|"Vee uit (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Wolk CSI-volume of plaaslike gasheerskyf?"}

    CloudOrLocal -->|"Wolk CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Gaan Wolkkonsole-asblik / Outomatiese EBS-snapshots / Ceph RBD-asblik na (rbd asblik ls)"]
    CloudOrLocal -->|"Plaaslike Node-skyf (plaaslike-pad / hostPath)"| StopDocker

    StopDocker --> RemountRO["Hermonteer Gasheerpartisie Leesalleen (mount -o remount,ro) OF Stroom Blokbeeld oor SSH"]
    RemountRO --> HostFS{"Watter lêerstelsel-gashere /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Gebruik debugfs / ext4magic Journal Inode Transaction Rollback (-'n tydstempel)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Gebruik Btrfs Roots / xfs_irecover / Custom Signature Carving vir SQLite, Postgres Heap of InnoDB .ibd"]

Fase 1: Hoe Docker en Kubernetes eintlik volumes op skyf uitvee¶

Voordat u enige herstelopdrag uitvoer, verstaan ​​waar u data fisies op die Linux-gasheer gewoon het en wat die uitvee-opdrag eintlik aangeraak het:

Fase 2: Red oop databasislêers van 'n houer wat nog loop (/proc/<pid>/fd/)¶

Wag: loop die houer tans nog? Dikwels voer 'n ingenieur 'n toepassingsmigrasieskrip, 'n opruimingswerk of 'n handleiding uit rm -rf /var/lib/postgresql/data/* of rm /app/data/production.sqlite3 binne 'n lopende houer, of vee die onderliggende gasheer bind-berg-lêergids uit /opt/app/data terwyl die houer self (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) is nog aan die gang.

In Linux word 'n lêer nie van skyf verwyder wanneer rm of unlink() genoem word. Sy skyfblokke en inode bly 100 persent toegewys en leesbaar tot die laaste proses met 'n oop lêerbeskrywing (FD) na daardie inode maak dit toe of gaan uit.

Stap 1: Vind die gasheerproses-ID (PID) van die houerproses¶

Op die Linux-gasheernodus (nie binne die houer nie), vind die gasheer PID van jou databasis of aansoekproses:

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)

Stap 2: Kopieer die ontkoppelde databasislêers reguit uit /proc/<PID>/fd/¶

Moenie die houer stop of herbegin nie. Terwyl die proses nog aan die gang is, kopieer die rou lêerbeskrywings direk na 'n veilige vouer op jou gasheer:

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

Stap 3: Selfs beter: Begin 'n regstreekse logiese stortingsterrein (pg_dump / mysqldump / .backup) voordat die houer die FD's toemaak¶

As postgres of mysqld loop steeds met sy datalêers oop in die geheue en /proc/<PID>/fd/, probeer eers 'n regstreekse logiese storting oor die bestaande Unix-sok of TCP-verbinding laat loop:

# 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

Fase 3: Herstel 'n geskrap Docker-volume aan ext4 of XFS nadat die houer gestop het¶

Wat as jy gehardloop het docker compose down -v of docker system prune --volumes, so die houer is reeds gestop en al /proc/<pid>/fd/ beskrywings is gesluit? Nou is jy in 'n wedloop teen agtergrondskyfskryf op die Linux-gasheer.

Stap 1: Vries die Linux-gasheerlêerstelsel binne 10 sekondes¶

1. Stop Docker, containerd, kubelet en cron onmiddellik sodat geen houer, healthcheck of log rotator nog 'n greep skryf na /var/lib/docker:

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

2. ** Kyk watter bloktoestel en lêerstelsel hou /var/lib/docker**:

   df -Th /var/lib/docker
   

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

3. ** Hermonteer die partisie Leesalleen (of stroom 'n rou partisiebeeld oor SSH na 'n ander masjien)**:
4. As /var/lib/docker is op sy eie toegewyde partisie of LVM-volume (byvoorbeeld /dev/nvme0n1p2 of /dev/mapper/vg0-docker), herstel dit onmiddellik leesalleen:

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

5. As /var/lib/docker is op die wortel / partisie (/), probeer om die wortelpartisie leesalleen te dwing deur die kern Magic SysRq-sneller (echo u | sudo tee /proc/sysrq-trigger) of sudo mount -o remount,ro /.
6. As jy op 'n wolk-VPS is (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Gaan onmiddellik na jou wolkwebkonsole en klik Skep momentopname op die bediener se blokvolume (of stroom die rou bloktoestel oor SSH na 'n tweede bediener: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Stap 2: Kyk of jou data nog in NOG 'n ongesnoeide volume sit of overlay2 laag¶

Voordat jy nie-toegekende skyfblokke kerf, verifieer dat jou databasis nie werklik in 'n bindberg of 'n ander benoemde volume gestoor is wat oorleef het nie:

# 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

Stap 3: Herstel ontkoppelde Docker-volumegidse aan ext4 die gebruik van die ext4 Joernaal (ext4magic en debugfs)¶

Wanneer docker volume rm skrap /var/lib/docker/volumes/<vol_name>/_data op 'n ext4 lêerstelsel, ext4 nul die direkte blokwysers uit (i_block / mate boomwortel) in die lewendige inode-tabel. Die ext4 joernaal (inode <8>, tipies 128 MB aan 1024 MB sirkelringbuffer) hou steeds historiese kopieë van die presiese inode-tabelle en gidsblokke van reg voor docker compose down -v tereggestel is.

+-------------------------------------------------------------------------+
| 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.        |
+-------------------------------------------------------------------------+

Hardloop ext4magic teen jou leesalleen-partisie (of die .img momentopname kopie op 'n tweede bediener), wat 'n tydstempel spesifiseer (-a) van 5 minute voor jy gehardloop het docker compose down -v of 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

Stap 4: Kerf rou SQLite-, PostgreSQL- of MySQL InnoDB-lêers uit wanneer die joernaal toegedraai is (XFS of ext4)¶

As die gasheer ** gebruikXFS** of as die ext4 joernaal reeds oor die inodewysers toegedraai, gebruik handtekening en struktuurkerf teen die rou skyfbeeld (docker_host_raw.img):

1. Vir SQLite3-databasisse (.sqlite, .db - bv. Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Elke SQLite3-databasis begin met 'n onmiskenbare 16-grepe ASCII-kopskrif by greep 0 van sy eerste 4 kilogrepe-bladsy: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), en stoor die presiese databasisbladsygrootte (Bytes 16..17, tipies 4096) en totale databasisgrootte in bladsye (Bytes 28..31, groot-endian 32-bis heelgetal) reg binne dieselfde kop.
2. Hardloop PhotoRec met [File Opt] -> [x] sqlite geaktiveer, of skandeer die partisie direk met grep -ab "SQLite format 3" om die presiese greepafset van jou geskrap SQLite-lêer te vind en dit uit te haal dd:

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

   Sodra dit onttrek is, hardloop sqlite3 carved.db ".recover" | sqlite3 repaired.db om elke ongeskonde B-boomblaarbladsy te rekonstrueer.

1. Vir MySQL / MariaDB InnoDB (.ibd tabellêers): Elke InnoDB .ibd tabel bestaan uit opeenvolgende 16 KB (16,384 byte) bladsye wat die FIL_PAGE_INDEX (0x45BF) kopskrif en die tabel is uniek space_id. Gebruik die Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) gereedskapstel om te skandeer /dev/nvme0n1p1 vir almal 16 KB InnoDB-indeksbladsye en stort elke ry direk in TSV/SQL-lêers vir herinvoer.
2. Vir PostgreSQL-hooplêers ($PGDATA/base/<db_oid>/<relfilenode>): PostgreSQL stoor elke tabel as aaneenlopend 8 KB (8,192 greep) hoop bladsye wat bevat PageHeaderData (pd_lower, pd_upper, pd_special). Gebruik pg_filedump of pglazarus / pdu om ongeallokeerde skyfstreke te skandeer 8 KB bladsye wat ooreenstem met jou tabel se kolom tuple uitleg (HeapTupleHeaderData) en rekonstrueer die rye.

Fase 4: Kubernetes PVC, PV, en etcd Momentopname Noodherstel¶

In Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), per ongeluk 'n PersistentVolumeClaim uitvee (kubectl delete pvc), 'n StatefulSet, of 'n hele naamruimte (kubectl delete ns prod) volg 'n heel ander argitektuur as selfstandige Docker.

Scenario A: Die PVC wys Terminating (The Finalizer Lifesaver)¶

Hardloop:

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

Scenario B: Die PVC is uitgevee, en kubectl get pv wys die PersistentVolume in Released staat (ReclaimPolicy: Retain)¶

Hardloop:

kubectl get pv

Hoe om 'n Released PV Available weer in 10 sekondes met geen dataverlies nie: 1. Wysig die PersistentVolume-voorwerp en vee die spec.claimRef blok:

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

Scenario C: Herstel van 'n uitgevee Kubernetes-klustertoestand vanaf 'n etcd momentopname (etcdctl snapshot restore)¶

Wat as iemand gehardloop het kubectl delete namespace prod of helm uninstall en het 200 Kubernetes-manifeste, geheime, konfigurasiekaarte en PV-definisies uitgewis op 'n selfbestuurde kubeadm, k3s, of RKE2 beheer vliegtuig?

1. ** Soek jou nuutste etcd momentopname** (by verstek in /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, of jou geskeduleerde /var/backups/etcd/snapshot.db).
2. Verifieer die momentopname-integriteit voordat jy die lewendige groep aanraak:

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

3. Stop kube-apiserver en etcd op die beheervlak nodus(s):
4. Op kubeadm (statiese peule): Beweeg /etc/kubernetes/manifests/kube-apiserver.yaml en /etc/kubernetes/manifests/etcd.yaml tydelik aan /root/manifests_hold/ so kubelet stop albei houers skoon en maak dan terug /var/lib/etcd aan /var/lib/etcd.bak.
5. Op k3s: Hardloop sudo systemctl stop k3s en sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** Herstel die etcd datagids aan 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. Beweeg etcd.yaml en kube-apiserver.yaml terug in /etc/kubernetes/manifests/. Binne 30 sekondes, kube-apiserver koppel weer aan die gerestoureerde etcd stoor en elke geskrapte Namespace-, Secret-, ConfigMap- en PersistentVolume-voorwerp verskyn weer.

Fase 5: Verhard Docker- en Kubernetes-volumes teen toevallige uitvee¶

Sodra jou produksiedatabasis herstel is, implementeer hierdie vier argitektoniese veiligheidsrelings sodat 'n enkele CLI-tikfout nooit weer 'n lewendige volume kan uitvee nie:

• ** Verander elke produksie Kubernetes StorageClass van reclaimPolicy: Delete aan reclaimPolicy: Retain**: By verstek, ingeboude wolk Storage Classes (gp2, gp3, standard-rwo) verstek na reclaimPolicy: Delete, wat beteken dat die verwydering van 'n PVC die wolkskyf vernietig. Skep 'n StorageClass met reclaimPolicy: Retain (of pleister bestaande PV's met kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') so die verwydering van 'n PVC of Naamruimte verwyder nooit die onderliggende blokvolume nie.
• Aktiveer AWS EBS-asblik / GCP-kiekieskedules / Velero met CSI-kiekies: Aktivering van AWS EBS-asblik behou enige geskrapte EBS-volume vir 7 tot 30 dae, selfs al bel die CSI-bestuurder DeleteVolume.
• ** Moet nooit gebruik nie docker system prune --volumes in outomatiese opruimingsskrifte of CI/CD-lopers**: As 'n produksiedatabasishouer kortstondig ineenstort (Exited (1)) op die presiese oomblik wat 'n cron-taak loop docker system prune -a --volumes -f, Docker beskou sy anonieme volumes as "ongebruik" en vee dit permanent uit. Strook --volumes van alle opruimingsskrifte.
• Gebruik eksplisiete gasheerbindings (/srv/prod_data/postgres:/var/lib/postgresql/data) of eksterne bestuurde databasisse vir statige produksiewerkladings: Anders as /var/lib/docker/volumes/, gasheer bind-berg dopgehou buite /var/lib/docker/ word nooit aangeraak nie docker compose down -v, docker volume rm, of docker system prune --volumes.

Streeksnoodnommers en agentskapprotokolle¶

Wanneer 'n houer- of Kubernetes-berging-uitvee 'n impak het op kliniese bedrywighede, openbare veiligheid of gereguleerde persoonlike data, eskaleer onmiddellik:

• Verenigde State en Kanada: Skakel 911 as 'n houerklustermislukking kliniese pasiëntmonitering, EHR-stelsels of noodversending deaktiveer. Rapporteer kwaadwillige houerinfrastruktuur-afvee of kubervoorvalle by CISA (1-844-Say-CISA / cisa.gov/report) of die Kanadese Sentrum vir Kuberveiligheid (1-833-CYBER-88).
• Verenigde Koninkryk: Skakel 999 vir lewensbedreigings of kritieke NHS-infrastruktuur. Onder Britse GDPR vereis permanente vernietiging of verlies van beskikbaarheid van persoonlike data sonder 'n herwinbare rugsteun 'n 72-uur-oortredingkennisgewing aan die ICO (0303 123 1113).
• Europese Unie: Skakel 112 in alle EU-lidlande. Entiteite onder die NIS2-richtlijn moet 'n vroeë waarskuwing by hul nasionale CSIRT indien binne 24 uur van 'n ernstige diensonderbreking, en permanente verlies van persoonlike data veroorsaak GDPR Artikel 33-verslagdoening binne 72 uur.
• Australië en Nieu-Seeland: Skakel 000in Australië of 111 in Nieu-Seeland; rapporteer kritieke infrastruktuurvoorvalle aan die ACSC (1300 CYBER1).
• Indië en Asië-Stille Oseaan: Skakel 112 in Indië vir noodreaksie; rapporteer wolk- of houersekuriteitsinsidente aan CERT-In (incident@cert-in.org.in) binne die verpligte 6-uur-venster.

Gereelde vrae¶

Doen docker compose down -v skrap gasheer binding mounts (./data:/var/lib/mysql) of slegs Named en Anonymous Docker-volumes?¶

`docker compose down -v` Skrap SLEGS Benoemde volumes verklaar in die `volumes:` afdeling van `docker-compose.yml` en Anonieme volumes wat aan die houers geheg is; dit nooit verwyder lêers binne 'n gasheerbindberg (soos `- /opt/mysql_data:/var/lib/mysql` of `- ./postgres_data:/var/lib/postgresql/data`). As jou skryflêer 'n gasheerpad gebruik het wat begin met `/` of `./`, kyk nou na daardie vouer op die gasheer: jou lêers is nog 100 persent ongeskonde.

Hoekom het docker system prune --volumes my databasisvolume uitvee toe ek die houer net vir 2 minute gestop het om 'n omgewingsveranderlike op te dateer?¶

Wag versigtig vir die onderskeid tussen `docker stop` en `docker rm`: as 'n houer bloot is `Stopped / Exited` (sigbaar in `docker ps -a`), `docker system prune --volumes` doen nie vee sy volumes uit omdat die gestopte houer steeds daarna verwys. As jy egter gehardloop het `docker rm ` (om die houer met nuwe vlae te herskep) of as jy geslaag het `docker system prune -a --volumes` (wat eers alle gestopte houers uitvee en dan verwyder alle volumes wat nie meer aan enige houer geheg is nie), het die volume "hangend" geraak die millisekonde wat die gestopte houer verwyder is en onmiddellik daarna afgevee is.

Kan ek 'n verwyderde Docker-volume binne Docker Desktop op 'n Mac herstel (Apple Silicon / Intel) of Windows (WSL2)?¶

Ja, as jy Docker Desktop onmiddellik verlaat sodat die virtuele masjien ophou loop `fstrim` teen die virtuele skyf. Op macOS stoor Docker alle Linux-volumes binne `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; op Windows WSL2, binne `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Kopieer dit `.raw` of `.vhdx` lêer onmiddellik na 'n eksterne SSD, heg dit leesalleen in Linux (met `losetup -Pr` vir `.raw` of `qemu-nbd -r` vir `.vhdx`), en hardloop `ext4magic` of `PhotoRec` teen die virtuele `ext4` afskorting binne.

Wat as ek 'n Kubernetes StatefulSet verwyder het kubectl delete statefulset postgres? Het dit my PVC's ook uitgevee?¶

Nee. By verstek in Kubernetes (tensy `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` is uitdruklik gekonfigureer op Kubernetes 1.27+), loop `kubectl delete statefulset` verwyder die StatefulSet-beheerder en sy peule, alles verlaat `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) en hul onderliggende data 100 persent ongeskonde. Pas eenvoudig jou `StatefulSet` YAML-manifes met dieselfde naam en `volumeClaimTemplates`, en die nuwe Pods sal outomaties weer aan die bestaande heg `data-postgres-0` PVC's.

Hoe kry ek toegang tot lêers binne 'n Docker overlay2 gids wanneer die houer weier om te begin (CrashLoopBackOff / Exited (1))?¶

Moenie die houer wat omgeval het uitvee nie. Solank die gestopte houer nog in bestaan `docker ps -a`, sy skryfbare laag en volume bevestigings is heeltemal ongeskonde op skyf. Jy kan óf lêers direk uit die gestopte houer kopieer met behulp van `docker cp :/var/lib/postgresql/data /root/rescued_data`, of vind sy presiese gasheer `overlay2` pad deur te hardloop `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` en lees daardie gids direk as `root`.

Wat as iemand 'n Kubernetes uitgevee het Namespace (kubectl delete ns prod) en alle PVC's gehad het reclaimPolicy: Delete op AWS EBS of GCP?¶

As die wolk CSI-bestuurder (`ebs.csi.aws.com` of `pd.csi.storage.gke.io`) reeds uitgevoer `DeleteVolume` want `reclaimPolicy` was `Delete`, gaan drie wolkvlak-veiligheidsnette onmiddellik na: (1) kontroleer **AWS-asblik vir EBS-volumes** in die AWS EC2-konsole (as 'n retensiereël aktief was op die rekening/etikette, sit die geskrap EBS-volume in die asblik en kan met 1 klik herstel word); (2) kyk na **AWS Backup / DLM / GCP Snapshot Schedules** vir die mees onlangse outomatiese volume momentopname; en (3) kyk of jou databasis WAL/binlogs gestroom het (`WAL-G`, `pgBackRest`, `Litestream`) na 'n S3/GCS-emmer.

Verwante gidse¶

• Bedienerskyf 100% vol (0 grepe gratis): databasis WAL-logopblaas, korrupte B-boom, en nul-spasie herstel
• Toevallige rm -rf of Shift+Delete op Linux, macOS of Windows: onmiddellike leesalleen-hermontering en inode-kerf
• Virtuele masjien VMDK, VHDX, en qcow2 momentopname ketting korrupsie en hipervisor redding
• Toevallige Git-toegang van AWS-sleutels, .env-lêer of private SSH-sleutel na publieke GitHub-repo
• Webgasheerkrisis, migrasie en herstel van rugsteun
• Rekenaarrugsteun, die 3-2-1-strategie en rampherstel
• Noodnommers volgens land

Bronne en amptelike leiding¶

• Kubernetes Amptelike Dokumentasie (kubernetes.io / Cloud Native Computing Foundation): Beskerming vir bergingvoorwerp in gebruik (kubernetes.io/pvc-protection Finaliseerders), Herwin Persistent Volumes (Retain vs. Delete), en Bedryf etcd Klusters vir Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Bestuur data in Docker: Volumes, Bind Mounts, overlay2 Bergingbestuurder-argitektuur, en snoei-verwysing.
• Die Linux Kernel Organisasie (kernel.org): Die /proc Lêerstelsel (procfs Open File Descriptor Recovery via /proc/<pid>/fd/) en Ext4 Joernaalspesifikasie.
• ext4magic Projekdokumentasie (ext4magic.sourceforge.net): Forensiese inode en joernaaltransaksieherwinning op Ext3/Ext4-lêerstelsels.
• Nasionale Instituut vir Standaarde en Tegnologie (NIST) (Verenigde State): Spesiale publikasie 800-190: Application Container Security Guide & Incident Recovery.