Docker eða Kubernetes framleiðslumagni eytt: Björgun docker system prune --volumes, overlay2 Inodes, og etcd Skyndimyndir¶

Hlaupandi docker compose down -v, docker system prune -a --volumes, docker volume rm, eða kubectl delete pvc á röngum flugstöðvarflipa í framleiðslu er ein fljótlegasta leiðin til að þurrka lifandi PostgreSQL, MySQL, MariaDB, Redis, MongoDB eða SQLite gagnagrunnsmagn. Ólíkt skyndimyndum af sýndarvél úr skýi sem færast í 7 daga ruslakörfu, er staðbundinn bindistjóri Docker (/var/lib/docker/volumes/<name>/_data) og Kubernetes local-path / hostPath veitendur gefa strax út staðal POSIX unlink() og rmdir() kallar beint á undirliggjandi Linux hýsingarkerfi (ext4, XFS, eða Btrfs). Sérhver skrif sem á sér stað á þeim Linux hýsingaraðila eftir að skipuninni lýkur getur skrifað yfir losaðar gagnagrunnsblokkir á disknum. Ef netþjónsdiskurinn þinn fylltist 100 prósent (0 bytes free) áður en einhver hljóp docker system prune --volumes í læti, ráðfærðu þig miðlara diskur 100% fullur, gagnagrunnur WAL log uppþemba, og núll-rými bati; fyrir hreinmálm Linux skrá eyðingu utan gáma, sjá óvart rm -rf eða Shift-Delete á ext4, XFS, APFS og NTFS: skrifvarinn endurfesting og inode útskurður og sýndarvél VMDK, VHDX og qcow2 skyndimynd keðjuspilling og björgun hásjávar. Ef þessi framleiðslustöðvun hefur áhrif á umönnun sjúklinga á sjúkrahúsi, neyðarsendingu eða öryggiskerfi almenningsveitna skaltu hringja í neyðarnúmerið þitt (911 í Bandaríkjunum og Kanada, 112 víðsvegar um Evrópusambandið, 999 í Bretlandi) eða skoðaðu skrána okkar yfir neyðarnúmer.

Gerðu þetta núna¶

1. EKKI hlaupa docker compose up -d, systemctl restart docker, eða endursetja Kubernetes hólf: Með því að endurskapa ílátið eða endurræsa Docker púkann skrifar megabæt af nýjum overlay2 lýsigögn, gáma JSON logs og nýuppstilltar tómar gagnagrunnsskrár (initdb) beint yfir nákvæmlega ext4 eða XFS blokkir þar sem hljóðstyrkurinn sem var eytt var til staðar fyrir sekúndum.
2. ** Athugaðu í 5 sekúndur ef gámaferlið (postgres, mysqld, redis-server, node, python) er enn í gangi í minni (ps aux og sudo lsof +L1)**: Ef einhver eyddi skrám í uppsettu bindi eða aftengdi nafnlaust bindi meðan gámurinn er enn í gangi heldur Linux kjarninn 100 prósent af ótengdum gagnagrunnsskrám lifandi á disknum svo framarlega sem hýsilsins Process ID (PID) hefur opinn skráarlýsingu (FD). Þú getur afritað þessar skrár beint út úr /proc/<PID>/fd/ eða /proc/<PID>/root/ með núll gagnatapi áður en ílátið stoppar.
3. Ef ílátið er þegar stöðvað og hljóðstyrknum var eytt (docker compose down -v eða docker system prune --volumes), frystu gestgjafi diskur skrifar strax: Stöðva Docker púkinn (sudo systemctl stop docker.socket docker.service containerd) so background containers and healthchecks stop writing logs into /var/lib/docker, þá annað hvort aftur /var/lib/docker (eða rótin / skipting) skrifvarinn (sudo mount -o remount,ro /) or take an immediate block-level cloud volume snapshot (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) before touching anything.
4. If you are on Kubernetes (kubectl delete pvc eða kubectl delete namespace), check the PersistentVolume (PV) ReclaimPolicy (kubectl get pv) strax:
5. If the PV had persistentVolumeReclaimPolicy: Retain, your data is not deleted: the PV simply moved to Released status and your cloud disk (EBS, Azure Disk, Ceph RBD, NFS) is 100 percent intact.
6. Even if kubectl delete pvc is stuck in Terminating, Kubernetes Finalizers (kubernetes.io/pvc-protection) block the CSI driver from deleting the underlying storage as long as any Pod still references that PVC. Do not delete the Pod until you copy the data out of the running Pod.
7. Image the underlying block partition (dd / ddrescue over SSH) to an external disk or separate cloud volume before running ext4magic, extundelete, eða PhotoRec: Never run file carvers that write output files onto the same disk partition from which you are recovering /var/lib/docker/volumes.
8. For corrupted or accidentally wiped Kubernetes cluster state (kubectl delete crd / namespace), stop kube-apiserver and restore your latest etcd snapshot (etcdctl snapshot restore): If the cluster state in etcd was wiped while the underlying cloud storage volumes still exist, restoring etcd endurheimtir allt PV, PVC, Secret, og ConfigMap hlutir samtímis.

Ákvörðunartré: eytt Docker bindi, overlay2 lag, eða Kubernetes PVC triage¶

Notaðu þetta flæðirit til að velja hraðvirkustu endurheimtarleiðina fyrir núll tap byggt á því hvort gámaferlið sé enn á lífi, hvort hljóðstyrkurinn hafi verið studdur af staðbundnum diski eða CSI geymslu í skýi og hvaða skráarkerfi hýsir /var/lib/docker:

flowchart TD
    Start["Framleiðslugögn vantar eftir Docker eða Kubernetes Delete Command"] --> WhichEnv{"Hvaða pallur og stjórn olli tapinu?"}

    WhichEnv -->|"Docker: gámur enn í gangi (skrár ótengdar inni í bindi/íláti)"| ProcRescue["Bjarga opnum ótengdum skráarlýsingum með sudo lsof +L1 og /proc/PID/fd/N eða /proc/PID/root/"]

    WhichEnv -->|"Docker: Gámur stöðvaður og bindi eytt (semja niður -v / prune --volumes)"| StopDocker["Hlaupa strax: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl eyða pvc / pv / statefulset / nafnrými"| K8sCheck{"Er fræbelgurinn enn í gangi EÐA er PVC fastur í lokun?"}

    K8sCheck -->|"Já: Pod Enn í gangi (Finalizer hindrar CSI Delete)"| K8sExec["EKKI eyða Pod -> Keyra kubectl exec / pg_dump / tar yfir stdout á staðbundinn disk strax"]
    K8sCheck -->|"Nei: Pod Gone -> Athugaðu kubectl fá pv"| ReclaimCheck{"Hvað var PV Reclaim Policy?"}

    ReclaimCheck -->|"Halda (PV Staða = Gefin út)"| ClearClaimRef["100% gögn ósnortin -> Breyta PV til að fjarlægja spec.claimRef.uid -> Endurbinda við nýtt PVC"]
    ReclaimCheck -->|"Eyða (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Cloud CSI Volume eða Local Host Disk?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Athugaðu ruslafötuna úr Cloud Console / Sjálfvirkar EBS skyndimyndir / Ceph RBD rusl (rbd rusl ls)"]
    CloudOrLocal -->|"Local Node Disk (local-path / hostPath)"| StopDocker

    StopDocker --> RemountRO["Endurtengja hýsingarskiptingu skrifvarið (mount -o remount,ro) EÐA Straumaðu blokkamynd yfir SSH"]
    RemountRO --> HostFS{"Hvaða skráakerfi hýsir /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Notaðu villuleit / ext4magic Journal Inode Transaction Backback (-tímastimpill)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Notaðu Btrfs Roots / xfs_irecover / Custom Signature Carving fyrir SQLite, Postgres Heap eða InnoDB .ibd"]

Áfangi 1: Hvernig Docker og Kubernetes eyða í raun bindum á disknum¶

Áður en þú keyrir endurheimtarskipun skaltu skilja hvar gögnin þín bjuggu líkamlega á Linux hýsingaraðilanum og hvað eyða skipunin snerti í raun:

Stig 2: Að bjarga opnum gagnagrunnsskrám úr íláti sem er enn í gangi (/proc/<pid>/fd/)¶

Bíddu: er gámurinn enn í gangi núna? Oft keyrir verkfræðingur forritaflutningsforskrift, cron-hreinsunarvinnu eða handbók rm -rf /var/lib/postgresql/data/* eða rm /app/data/production.sqlite3 inni í gangi ílát, eða eyðir undirliggjandi host bind-mount möppu /opt/app/data á meðan ílátið sjálft (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) er enn í gangi.

Í Linux er skrá ekki eytt af disknum þegar rm eða unlink() heitir. Diskblokkir þess og inóða eru áfram 100 prósent úthlutað og læsileg þar til síðasta ferlið er með opna skráarlýsingu (FD) við það inode lokar það eða hættir.

Skref 1: Finndu auðkenni gestgjafaferlisins (PID) af gámaferlinu¶

Finndu hýsilinn á Linux hýsingarhnútnum (ekki inni í ílátinu). PID af gagnagrunninum þínum eða umsóknarferli:

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)

Skref 2: Afritaðu ótengdu gagnagrunnsskrárnar beint úr /proc/<PID>/fd/¶

Ekki **stöðva eða endurræsa ílátið. Á meðan ferlið er enn í gangi, afritaðu hráskráarlýsingarnar beint í örugga möppu á gestgjafanum þínum:

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

Skref 3: Jafnvel betra: Keyra lifandi rökrétt sorp (pg_dump / mysqldump / .backup) áður en ílátið lokar FDs¶

Ef postgres eða mysqld er enn í gangi með gagnaskrár sínar opnar í minni og /proc/<PID>/fd/, reyndu fyrst að keyra lifandi rökrétt dump yfir núverandi unix fals eða TCP tengingu:

# 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. áfangi: Endurheimt eytt Docker bindi á ext4 eða XFS eftir að gámurinn stöðvaðist¶

Hvað ef þú hleypur docker compose down -v eða docker system prune --volumes, þannig að gámurinn er þegar stöðvaður og allt /proc/<pid>/fd/ lýsingar eru lokaðar? Nú ertu í kapphlaupi við bakgrunnsdisk sem skrifar á Linux hýsilinn.

Skref 1: Frystu Linux hýsingarkerfið innan 10 sekúndna¶

1. Stöðvaðu Docker, containerd, kubelet og cron strax þannig að enginn gámur, heilsufarsskoðun eða annálarsnúningur skrifar annað bæti til /var/lib/docker:

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

2. ** Athugaðu hvaða blokkunartæki og skráarkerfi geymir /var/lib/docker**:

   df -Th /var/lib/docker
   

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

3. Tengdu aftur skiptinguna Read-Only (eða streymdu hrári skiptingarmynd yfir SSH á aðra vél):
4. Ef /var/lib/docker er á eigin sérstöku skiptingi eða LVM bindi (til dæmis /dev/nvme0n1p2 eða /dev/mapper/vg0-docker), settu það aftur skrifvarið strax:

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

5. Ef /var/lib/docker er á rótinni / skipting (/), reyndu að þvinga rótarskiptingu skrifvarið með því að nota kjarnann Magic SysRq kveikju (echo u | sudo tee /proc/sysrq-trigger) eða sudo mount -o remount,ro /.
6. Ef þú ert á VPS skýi (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Farðu strax á skýjavefborðið þitt og smelltu á Create Snapshot á blokkarmagni þjónsins (eða streymdu hráu blokkartækinu yfir SSH á annan netþjón: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Skref 2: Athugaðu hvort gögnin þín séu enn í ANNU óklipptu bindi eða overlay2 lag¶

Áður en óúthlutaðar diskablokkir eru skornar út skaltu ganga úr skugga um að gagnagrunnurinn þinn hafi ekki verið geymdur í bindingarfestingu eða öðru nafni bindi sem lifði af:

# 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

Skref 3: Endurheimt ótengdar Docker bindiskrár á ext4 með því að nota ext4 Dagbók (ext4magic og debugfs)¶

Hvenær docker volume rm eyðir /var/lib/docker/volumes/<vol_name>/_data á an ext4 skráarkerfi, ext4 núllar út beinu blokkavísana (i_block / umfang trjárótar) í lifandi inode töflunni. Hins vegar er ext4 dagbók (inode <8>, venjulega 128 MB til 1024 MB hringlaga hringja biðminni) geymir enn söguleg afrit af nákvæmum inode töflum og skráarblokkum frá rétt áður docker compose down -v var tekinn af lífi.

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

Hlaupa ext4magic gegn skrifvarið skiptingunni þinni (eða .img skyndimynd afrit á öðrum netþjóni), sem tilgreinir tímastimpil (-a) frá 5 mínútum áður þú hljóp docker compose down -v eða 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

Skref 4: Útskorið hráar SQLite, PostgreSQL eða MySQL InnoDB skrár þegar dagbókin hefur pakkað (XFS eða ext4)¶

Ef gestgjafinn notar XFS eða ef ext4 dagbók sem þegar er vafið yfir inode bendina, notaðu undirskrift og uppbyggingarskurð á móti hráu diskamyndinni (docker_host_raw.img):

1. Fyrir SQLite3 gagnagrunna (.sqlite, .db - t.d. Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Sérhver SQLite3 gagnagrunnur byrjar á ótvíræðum 16-bæta ASCII-haus á bæti 0 á fyrstu 4 kílóbæta síðu sinni: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), og geymir nákvæma gagnagrunnssíðustærð (Bytes 16..17, venjulega 4096) og heildarstærð gagnagrunns á síðum (Bytes 28..31, big-endian 32-bita heiltala) beint inni í sama haus.
2. Hlaupa PhotoRec með [File Opt] -> [x] sqlite virkt, eða skannaðu skiptinguna beint með grep -ab "SQLite format 3" til að finna nákvæma bætajöfnun á eyddum SQLite skránni þinni og draga hana út með dd:

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

   Þegar búið er að draga það út skaltu keyra sqlite3 carved.db ".recover" | sqlite3 repaired.db að endurgera hverja ósnortna B-tré laufsíðu.

1. Fyrir MySQL / MariaDB InnoDB (.ibd töfluskrár): Sérhver InnoDB .ibd tafla samanstendur af röð 16 KB (16,384 bæti) síður sem innihalda FIL_PAGE_INDEX (0x45BF) haus og borðið er einstakt space_id. Notaðu Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) verkfærakista til að skanna /dev/nvme0n1p1 fyrir alla 16 KB InnoDB skráarsíður og sendu hverja röð beint í TSV/SQL skrár til að flytja inn aftur.
2. Fyrir PostgreSQL hrúguskrár ($PGDATA/base/<db_oid>/<relfilenode>): PostgreSQL geymir hvert borð sem samliggjandi 8 KB (8,192 bæti) hrúgusíður sem innihalda PageHeaderData (pd_lower, pd_upper, pd_special). Notaðu pg_filedump eða pglazarus / pdu til að skanna óúthlutað disksvæði fyrir 8 KB síður sem passa við dálkauppsetningu töflunnar þinnar (HeapTupleHeaderData) og endurgerðu línurnar.

Áfangi 4: Kubernetes PVC, PV, og etcd Skyndimynd neyðarbata¶

Í Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), eyðir fyrir slysni PersistentVolumeClaim (kubectl delete pvc), StatefulSet eða heilt nafnarými (kubectl delete ns prod) fylgir mjög öðrum arkitektúr en sjálfstæður Docker.

Atburðarás A: PVC sýnir Terminating (The Finalizer Lifesaver)¶

Hlaupa:

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

Sviðsmynd B: PVC var eytt, og kubectl get pv sýnir PersistentVolume í Released ríki (ReclaimPolicy: Retain)¶

Hlaupa:

kubectl get pv

Hvernig á að búa til a Released PV Available aftur eftir 10 sekúndur án gagnataps: 1. Breyttu PersistentVolume hlutnum og eyddu spec.claimRef blokk:

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

Atburðarás C: Endurheimt þurrkað Kubernetes klasaástand frá an etcd snapshot (etcdctl snapshot restore)¶

Hvað ef einhver hljóp kubectl delete namespace prod eða helm uninstall og þurrkaði út 200 Kubernetes upplýsingaskrár, Secrets, Config Maps og PV skilgreiningar á sjálfstýrðri kubeadm, k3s, eða RKE2 stjórna flugvél?

1. ** Finndu nýjasta etcd skyndimynd** (sjálfgefið í /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, eða áætlun þinni /var/backups/etcd/snapshot.db).
2. Staðfestu heilleika skyndimyndarinnar áður en þú snertir lifandi þyrpinguna:

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

3. Hættu kube-apiserver og etcd á hnút/-um stjórnplans:
4. Á kubeadm (stöðugir belg): Færðu þig /etc/kubernetes/manifests/kube-apiserver.yaml og /etc/kubernetes/manifests/etcd.yaml tímabundið til /root/manifests_hold/ svo kubelet stöðvar báðar ílátin hreint og snýr síðan aftur upp /var/lib/etcd til /var/lib/etcd.bak.
5. Á k3s: Hlaupa sudo systemctl stop k3s og sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** Endurheimtu etcd gagnaskrá á 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. Færa etcd.yaml og kube-apiserver.yaml aftur inn í /etc/kubernetes/manifests/. Innan 30 sekúndna, kube-apiserver tengist aftur við endurheimt etcd geyma og sérhver eyddur Namespace, Secret, ConfigMap og PersistentVolume hlutur birtist aftur.

Áfangi 5: Herða Docker og Kubernetes bindi gegn eyðingu fyrir slysni¶

Þegar framleiðslugagnagrunnurinn þinn hefur verið endurheimtur skaltu innleiða þessar fjórar byggingarvarðar svo ein CLI innsláttarvilla geti aldrei eytt lifandi bindi aftur:

• Breyttu hverri framleiðslu Kubernetes StorageClass frá reclaimPolicy: Delete til reclaimPolicy: Retain: Sjálfgefið, innbyggðir skýjageymsluflokkar (gp2, gp3, standard-rwo) sjálfgefið til reclaimPolicy: Delete, sem þýðir að eyða PVC eyðileggur skýjadiskinn. Búðu til a StorageClass með reclaimPolicy: Retain (eða plástra núverandi PVs með kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') þannig að það að eyða PVC eða nafnrými eyðir aldrei undirliggjandi bindi.
• Virkja AWS EBS ruslatunnu / GCP skyndimyndaáætlanir / Velero með CSI skyndimyndum: Með því að virkja AWS EBS ruslatunnu geymir allt eytt EBS bindi í 7 til 30 daga jafnvel þótt CSI bílstjórinn hringi DeleteVolume.
• Aldrei nota docker system prune --volumes í sjálfvirkum hreinsunarforskriftum eða CI/CD hlaupurum: Ef framleiðslugagnagrunnsílát hrynur í stutta stund (Exited (1)) á nákvæmlega því augnabliki sem cron starf keyrir docker system prune -a --volumes -f, Docker telur nafnlaus bindi þess „ónotuð“ og eyðir þeim varanlega. Strip --volumes úr öllum hreinsunarforskriftum.
• Notaðu skýrar hýsilbindingar (/srv/prod_data/postgres:/var/lib/postgresql/data) eða utanaðkomandi stýrðum gagnagrunnum fyrir staðbundið framleiðsluálag: Ólíkt /var/lib/docker/volumes/, hýsir bind-mount möppur fyrir utan /var/lib/docker/ eru aldrei snert af docker compose down -v, docker volume rm, eða docker system prune --volumes.

Svæðisbundin neyðarnúmer og samskiptareglur stofnunarinnar¶

Þegar eyðing íláts eða Kubernetes geymslu hefur áhrif á klíníska starfsemi sjúkrahúss, sendingu almenningsöryggis eða eftirlitsskyldra persónuupplýsinga, skal stigmagnast strax:

• Bandaríkin og Kanada: Hringdu 911 ef bilun í gámaklasa gerir klínískt eftirlit með sjúklingum óvirkt, EHR kerfi eða neyðarsendingu. Tilkynna skaðlega eyðingu gámainnviða eða netatvik til CISA (1-844-Say-CISA / cisa.gov/report) eða Canadian Center for Cyber ​​Security (1-833-CYBER-88).
• Bretland: Hringdu 999 fyrir ógnir við líf eða mikilvægan innviði NHS. Samkvæmt GDPR í Bretlandi krefst varanleg eyðilegging eða tap á aðgengi að persónulegum gögnum án endurheimtanlegs öryggisafrits að metið sé 72 klukkustunda tilkynning um brot til ICO (0303 123 1113).
• Evrópusambandið: Hringja 112 í öllum aðildarríkjum ESB. Aðilar samkvæmt NIS2 tilskipuninni verða að senda inn viðvörun til innlendra CSIRT innan 24 klukkustunda frá alvarlegu þjónustuleysi og varanlegt tap á persónuupplýsingum kallar fram GDPR grein 33. grein tilkynningar innan 72 klukkustunda.
• Ástralía og Nýja Sjáland: Hringja 000 í Ástralíu eða 111 á Nýja Sjálandi; tilkynna mikilvæg innviðaatvik til ACSC (1300 CYBER1).
• Indland og Asíu-Kyrrahaf: Hringja 112 á Indlandi fyrir neyðarviðbrögð; tilkynntu öryggisatvik í skýi eða gámum til CERT-In (incident@cert-in.org.in) innan lögboðins 6 tíma glugga.

Algengar spurningar¶

Gerir það docker compose down -v eyða hýsilbindingum (./data:/var/lib/mysql) eða aðeins Named and Anonymous Docker bindi?¶

`docker compose down -v` AÐEINS eyðir nafngreindum bindum sem lýst er yfir í `volumes:` kafla af `docker-compose.yml` og nafnlaus bindi sem fylgja ílátunum; það aldrei eyðir skrám inni í host bind fjalli (svo sem `- /opt/mysql_data:/var/lib/mysql` eða `- ./postgres_data:/var/lib/postgresql/data`). Ef skrifa skráin þín notaði hýsilslóð sem byrjar á `/` eða `./`, athugaðu þá möppu á gestgjafanum núna: skrárnar þínar eru enn 100 prósent ósnortnar.

Hvers vegna gerði docker system prune --volumes eyða gagnagrunnsmagninu mínu þegar ég stoppaði aðeins ílátið í 2 mínútur til að uppfæra umhverfisbreytu?¶

Bíddu vandlega eftir greinarmun á milli `docker stop` og `docker rm`: ef ílát er eingöngu `Stopped / Exited` (sýnilegt í `docker ps -a`), `docker system prune --volumes` gerir ekki eyða bindum þess vegna þess að stöðvaði ílátið vísar enn til þeirra. Hins vegar, ef þú hljóp `docker rm ` (til að endurskapa gáminn með nýjum fánum) eða ef þú stóðst `docker system prune -a --volumes` (sem eyðir fyrst öllum stöðvuðum gámum og þá eyðir öllum bindum sem eru ekki lengur tengdir neinu íláti), rúmmálið varð að "hanggla" á millisekúndu sem stöðvað ílát var fjarlægt og var þurrkað strax eftir það.

Get ég endurheimt eytt Docker bindi inni í Docker Desktop á Mac (Apple Silicon / Intel) eða Windows (WSL2)?¶

Já, ef þú hættir strax í Docker Desktop svo sýndarvélin hætti að keyra `fstrim` á móti sýndardisknum. Á macOS geymir Docker öll Linux bindi inni `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; á Windows WSL2, inni `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Afritaðu það `.raw` eða `.vhdx` skrá strax á ytri SSD, hengja hana skrifvarið í Linux (með því að nota `losetup -Pr` fyrir `.raw` eða `qemu-nbd -r` fyrir `.vhdx`), og hlaupið `ext4magic` eða `PhotoRec` á móti sýndarverunni `ext4` skilrúm að innan.

Hvað ef ég eyddi Kubernetes StatefulSet með kubectl delete statefulset postgres? Eyddi það PVC-skjölunum mínum líka?¶

Nei. Sjálfgefið í Kubernetes (nema `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` var sérstaklega stillt á Kubernetes 1.27+), í gangi `kubectl delete statefulset` eyðir StatefulSet stjórnandanum og belgjum hans, yfirgefa allt `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) og undirliggjandi gögn þeirra 100 prósent ósnortinn. Notaðu einfaldlega aftur `StatefulSet` YAML upplýsingaskrá með sama nafni og `volumeClaimTemplates`, og nýju belgirnir festast sjálfkrafa aftur við það sem fyrir er `data-postgres-0` PVC.

Hvernig fæ ég aðgang að skrám inni í Docker overlay2 möppu þegar ílátið neitar að byrja (CrashLoopBackOff / Exited (1))?¶

Ekki eyða ílátinu sem hrundi. Svo lengi sem stöðvaði gámurinn er enn til í `docker ps -a`, skrifanlegt lag og hljóðstyrksfestingar eru alveg ósnortnar á disknum. Þú getur annað hvort afritað skrár beint úr stöðvuðu ílátinu með því að nota `docker cp :/var/lib/postgresql/data /root/rescued_data`, eða finndu nákvæman gestgjafa hans `overlay2` slóð með því að hlaupa `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` og lesa þá möppu beint sem `root`.

Hvað ef einhver eyddi Kubernetes Namespace (kubectl delete ns prod) og allir PVC-efni höfðu reclaimPolicy: Delete á AWS EBS eða GCP?¶

Ef ský CSI bílstjórinn (`ebs.csi.aws.com` eða `pd.csi.storage.gke.io`) þegar framkvæmd `DeleteVolume` vegna þess að `reclaimPolicy` var `Delete`, athugaðu strax þrjú öryggisnet á skýjastigi: (1) athugaðu **AWS ruslafötuna fyrir EBS bindi** í AWS EC2 stjórnborðinu (ef varðveisluregla var virk á reikningnum/merkjunum, þá situr eytt EBS rúmmálið í ruslafötunni og hægt er að endurheimta það með 1 smelli); (2) athugaðu **AWS Backup / DLM / GCP Snapshot Schedules** fyrir nýjustu sjálfvirku hljóðstyrksmyndina; og (3) athugaðu hvort gagnagrunnurinn þinn streymdi WAL/binlogs (`WAL-G`, `pgBackRest`, `Litestream`) í S3/GCS fötu.

Tengdir leiðsögumenn¶

• Miðlaradiskur 100% fullur (0 bæti ókeypis): WAL gagnagrunnsuppþemba, skemmd B-tré og núll-pláss endurheimt
• Óviljandi rm -rf eða Shift+Delete á Linux, macOS eða Windows: tafarlaus skrifvarinn endurfesting og inode útskurður
• Sýndarvél VMDK, VHDX og qcow2 skyndimyndakeðjuspilling og björgun hásjávar
• Óviljandi Git commit af AWS lyklum, .env skrá eða einka SSH lykil í opinbera GitHub endurhverfu
• Vefhýsingarkreppa, flutningur og endurheimt afritunar
• Tölvuafrit, 3-2-1 stefnan og hörmungarbati
• Neyðarnúmer eftir löndum

Heimildir og opinberar leiðbeiningar¶

• Opinber skjöl Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Vörn fyrir geymsluhlut í notkun (kubernetes.io/pvc-protection Finalizers), Reclaiming Persistent Volumes (Retain vs. Delete), og rekstur etcd Klasar fyrir Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Stjórna gögnum í Docker: Bindi, Bind Mounts, overlay2 Arkitektúr fyrir geymslubílstjóra og tilvísun til prune.
• Linux kjarnasamtökin (kernel.org): The /proc Skráarkerfi (procfs Opnaðu File Descriptor Recovery í gegnum /proc/<pid>/fd/) og Ext4 Journal Specification.
• ext4magic Verkefnaskjöl (ext4magic.sourceforge.net): Réttar inode and Journal Transaction Recovery on Ext3/Ext4 File Systems.
• National Institute of Standards and Technology (NIST) (Bandaríkin): Special Publication 800-190: Application Container Security Guide & Incident Recovery.