Docker alebo Kubernetes Production Volume odstránený: Záchrana docker system prune --volumes, overlay2 Inódy a etcd Snímky¶

Beh docker compose down -v, docker system prune -a --volumes, docker volume rm, alebo kubectl delete pvc na nesprávnej záložke terminálu vo výrobe je jedným z najrýchlejších spôsobov vymazania živého objemu databázy PostgreSQL, MySQL, MariaDB, Redis, MongoDB alebo SQLite. Na rozdiel od snímok virtuálneho počítača v cloude, ktoré sa presúvajú do 7-dňového koša, ovládač lokálneho zväzku Docker (/var/lib/docker/volumes/<name>/_data) a Kubernetes local-path / hostPath poskytovatelia okamžite vydajú štandardný POSIX unlink() a rmdir() volania priamo proti základnému hostiteľskému súborovému systému Linuxu (ext4, XFS, alebo Btrfs). Každý zápis, ku ktorému dôjde na tomto hostiteľovi Linuxu po dokončení príkazu, môže prepísať uvoľnené bloky databázy na disku. Ak je disk vášho servera zaplnený na 100 percent (0 bytes free) predtým, než niekto bežal docker system prune --volumes v panike sa poraďte disk servera je plný na 100 %, nafúknutie denníka databázy WAL a obnovenie s nulovým priestorom; pre vymazanie linuxových súborov mimo kontajnerov pozri náhodné rm -rf alebo Shift-Delete na ext4, XFS, APFS a NTFS: opätovné pripojenie len na čítanie a vyrezávanie inodov a virtuálny stroj VMDK, VHDX a qcow2 snapshot reťazové poškodenie a záchrana hypervízora. Ak tento výpadok výroby ovplyvní nemocničnú starostlivosť o pacientov, núdzovú prepravu alebo systémy verejnej služby, zavolajte na miestne tiesňové číslo (911 v Spojených štátoch a Kanade, 112 v celej Európskej únii, 999 v Spojenom kráľovstve) alebo si pozrite náš adresár tiesňové čísla.

Urobte to teraz¶

1. NEBEŽTE docker compose up -d, systemctl restart dockeralebo znova nasaďte modul Kubernetes: Opätovné vytvorenie kontajnera alebo reštartovanie démona Docker zapíše megabajty nových overlay2 metadáta, protokoly kontajnera JSON a čerstvo inicializované prázdne databázové súbory (initdb) priamo nad presným ext4 alebo XFS bloky, kde sa váš odstránený zväzok nachádzal pred sekundami.
2. **Skontrolujte o 5 sekúnd, ak proces kontajnera (postgres, mysqld, redis-server, node, python) stále beží v pamäti (ps aux a sudo lsof +L1(PID) má otvorený deskriptor súboru (FD). Tieto súbory môžete skopírovať priamo z /proc/<PID>/fd/ alebo /proc/<PID>/root/ s nulovou stratou údajov pred zastavením kontajnera.
3. Ak je kontajner už zastavený a zväzok bol odstránený (docker compose down -v alebo docker system prune --volumes), okamžite zmraziť zápisy na hostiteľský disk: Zastavte démona Docker (sudo systemctl stop docker.socket docker.service containerd), takže kontajnery na pozadí a zdravotné kontroly prestanú zapisovať prihlásenia /var/lib/docker, potom buď znova namontujte /var/lib/docker (alebo koreň / oddiel) len na čítanie (sudo mount -o remount,ro /) alebo okamžite urobte snímku objemu cloudu na úrovni bloku (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) predtým, než sa čohokoľvek dotknete.
4. Ak ste na Kubernetes (kubectl delete pvc alebo kubectl delete namespace), skontrolujte PersistentVolume (PV) ReclaimPolicy (kubectl get pv) okamžite:
5. Ak PV mal persistentVolumeReclaimPolicy: Retain, vaše údaje sa nevymažú: PV jednoducho sa presťahovali do Released stav a váš cloudový disk (EBS, Azure Disk, Ceph RBD, NFS) je 100 percent neporušená.
6. Aj keby kubectl delete pvc je zaseknutý v Terminating, Finalizátory Kubernetes (kubernetes.io/pvc-protection)** zablokuje ovládač CSI vo vymazaní základného úložiska, pokiaľ akýkoľvek modul stále odkazuje na toto PVC. Neodstraňujte modul, kým neskopírujete údaje z bežiaceho modulu.
7. Zobrazte základný oddiel bloku (dd / ddrescue cez SSH) na externý disk alebo samostatný cloudový zväzok pred spustením ext4magic, extundelete, alebo PhotoRec: Nikdy nespúšťajte rezačky súborov, ktoré zapisujú výstupné súbory na rovnakú diskovú oblasť, z ktorej obnovujete /var/lib/docker/volumes.
8. Pre poškodený alebo náhodne vymazaný stav klastra Kubernetes (kubectl delete crd / namespace), zastaviť kube-apiserver a obnovte svoje najnovšie etcd snímka (etcdctl snapshot restore): Ak je stav klastra v etcd bol vymazaný, zatiaľ čo základné objemy cloudového úložiska stále existujú, obnovuje sa etcd obnoví všetko PV, PVC, Secret, a ConfigMap objekty súčasne.

Rozhodovací strom: odstránený zväzok Docker, overlay2 vrstva alebo triedenie PVC Kubernetes¶

Pomocou tohto vývojového diagramu vyberte najrýchlejšiu cestu obnovy s nulovou stratou na základe toho, či je proces kontajnera stále aktívny, či bol zväzok zálohovaný lokálnym diskom alebo cloudovým úložiskom CSI a ktorý súborový systém je hostiteľom. /var/lib/docker:

flowchart TD
    Start["Po príkaze na odstránenie Dockera alebo Kubernetes chýbajú produkčné údaje"] --> WhichEnv{"Ktorá platforma a velenie spôsobili stratu?"}

    WhichEnv -->|"Docker: Kontajner je stále spustený (súbory sú odpojené vo vnútri zväzku/kontajnera)"| ProcRescue["Záchrana otvorených deskriptorov neprepojených súborov cez sudo lsof +L1 a /proc/PID/fd/N alebo /proc/PID/root/"]

    WhichEnv -->|"Docker: Kontajner zastavený a zväzok odstránený (založiť -v / prerezať --volumes)"| StopDocker["Okamžite spustiť: sudo systemctl stop docker.socket docker kontajnera"]

    WhichEnv -->|"Kubernetes: kubectl odstrániť pvc / pv / statefulset / menný priestor"| K8sCheck{"Je podložka stále v prevádzke ALEBO je PVC zaseknuté v koncovke?"}

    K8sCheck -->|"Áno: Pod stále beží (finalizátor blokuje odstránenie CSI)"| K8sExec["NEODSTRAŇUJTE POD -> Okamžite spustite kubectl exec / pg_dump / tar cez stdout na lokálny disk"]
    K8sCheck -->|"Nie: Pod Gone -> Check kubectl get pv"| ReclaimCheck{"Čo bolo PV ReclaimPolicy?"}

    ReclaimCheck -->|"Zachovať (stav PV = uvoľnené)"| ClearClaimRef["100 % neporušené údaje -> Upraviť PV na odstránenie spec.claimRef.uid -> Znovu naviazať na nové PVC"]
    ReclaimCheck -->|"Odstrániť (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Cloudový zväzok CSI alebo lokálny hostiteľský disk?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Skontrolujte kôš cloudovej konzoly / automatizované snímky EBS / kôš Ceph RBD (rbd trash ls)"]
    CloudOrLocal -->|"Lokálny disk uzla (lokálna cesta / hostPath)"| StopDocker

    StopDocker --> RemountRO["Znovu pripojiť hostiteľský oddiel len na čítanie (mount -o remount,ro) ALEBO Streamovať obraz bloku cez SSH"]
    RemountRO --> HostFS{"Aký súborový systém je hostiteľom /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Použiť debugfs / ext4magic Journal Inode Transaction Rollback (-a časová pečiatka)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Použite Btrfs Roots / xfs_irecover / Custom Signature Carving pre SQLite, Postgres Heap alebo InnoDB .ibd"]

Fáza 1: Ako Docker a Kubernetes skutočne odstraňujú zväzky na disku¶

Pred spustením akéhokoľvek príkazu na obnovenie zistite, kde sa vaše údaje fyzicky nachádzali na hostiteľovi systému Linux a čoho sa príkaz na odstránenie skutočne dotkol:

Fáza 2: Záchrana otvorených databázových súborov zo stále spusteného kontajnera (/proc/<pid>/fd/)¶

Počkajte: je kontajner práve teraz spustený? Inžinier často spúšťa skript migrácie aplikácie, úlohu vyčistenia cron alebo príručku rm -rf /var/lib/postgresql/data/* alebo rm /app/data/production.sqlite3 vnútri spusteného kontajnera alebo vymaže základný priečinok pripojenia hostiteľa /opt/app/data zatiaľ čo samotný kontajner (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) je stále v prevádzke.

V Linuxe sa súbor nevymaže z disku, keď rm alebo unlink() sa volá. Jeho diskové bloky a inode zostávajú 100 percent alokované a čitateľné až do posledného procesu, ktorý má otvorený deskriptor súboru (FD) do tohto inodu ho zatvorí alebo vystúpi.

Krok 1: Nájdite ID hostiteľského procesu (PID) kontajnerového procesu¶

V hostiteľskom uzle Linuxu (nie v kontajneri) nájdite hostiteľa PID vašej databázy alebo procesu aplikácie:

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)

Krok 2: Skopírujte neprepojené databázové súbory priamo z /proc/<PID>/fd/¶

Nádobu nezastavujte ani nereštartujte. Kým proces stále beží, skopírujte nespracované deskriptory súborov priamo do bezpečného priečinka na vašom hostiteľovi:

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

Krok 3: Ešte lepšie: Spustite živý logický výpis (pg_dump / mysqldump / .backup) predtým, ako kontajner uzavrie FD¶

Ak postgres alebo mysqld stále beží s dátovými súbormi otvorenými v pamäti a /proc/<PID>/fd/, skúste najskôr spustiť živý logický výpis cez existujúci soket Unix alebo pripojenie 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

Fáza 3: Obnovenie odstráneného zväzku Docker zapnuté ext4 alebo XFS po zastavení kontajnera¶

Čo keby si bežal docker compose down -v alebo docker system prune --volumes, takže kontajner je už zastavený a všetko /proc/<pid>/fd/ sú deskriptory zatvorené? Teraz ste v pretekoch so zápismi na disk na pozadí na hostiteľovi Linuxu.

Krok 1: Zmrazte hostiteľský súborový systém Linux do 10 sekúnd¶

1. Okamžite zastavte Docker, kontajner, kubelet a cron, takže žiadny kontajner, kontrola stavu ani rotátor protokolu nezapíše ďalší bajt do /var/lib/docker:

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

2. Skontrolujte, ktoré blokové zariadenie a súborový systém obsahuje /var/lib/docker:

   df -Th /var/lib/docker
   

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

3. Znova pripojte oddiel len na čítanie (alebo streamujte nespracovaný obraz oddielu cez SSH do iného počítača):
4. Ak /var/lib/docker je na vlastnom vyhradenom oddiele alebo zväzku LVM (napr /dev/nvme0n1p2 alebo /dev/mapper/vg0-docker), okamžite ho znova pripojte len na čítanie:

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

5. Ak /var/lib/docker je na koreni / oddiel (/), skúste vynútiť koreňový oddiel iba na čítanie pomocou spúšťača kernel Magic SysRq (echo u | sudo tee /proc/sysrq-trigger) alebo sudo mount -o remount,ro /.
6. Ak používate cloudové VPS (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Ihneď prejdite do svojej cloudovej webovej konzoly a kliknite na Vytvoriť snímku na zväzku blokov servera (alebo streamujte nespracované blokové zariadenie cez SSH na druhý server: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Krok 2: Skontrolujte, či sú vaše dáta stále uložené v INOM neorezanom zväzku alebo overlay2 vrstva¶

Pred vyrezaním nepridelených diskových blokov si overte, či vaša databáza v skutočnosti nebola uložená vo väzbe alebo inak pomenovanom zväzku, ktorý prežil:

# 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

Krok 3: Obnovenie neprepojených adresárov zväzkov Docker zapnuté ext4 pomocou ext4 Denník (ext4magic a debugfs)¶

Kedy docker volume rm vymaže /var/lib/docker/volumes/<vol_name>/_data na an ext4 súborový systém, ext4 vynuluje priame ukazovatele bloku (i_block / koreňový strom rozsahu) v tabuľke živých inodov. Avšak ext4 denník (inode <8>, zvyčajne 128 MB do 1024 MB kruhová kruhová vyrovnávacia pamäť) stále obsahuje historické kópie presných tabuliek inodov a blokov adresárov z predchádzajúceho obdobia docker compose down -v bol popravený.

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

Bežať ext4magic proti vášmu oddielu iba na čítanie (alebo .img kópia snímky na druhom serveri) s uvedením časovej pečiatky (-a) od 5 minút predtým, než ste bežali docker compose down -v alebo 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

Krok 4: Vyrezávanie nespracovaných súborov SQLite, PostgreSQL alebo MySQL InnoDB po zabalení denníka (XFS alebo ext4)¶

Ak hostiteľ používa XFS alebo ak ext4 žurnál už zabalený cez ukazovatele inodov, použite podpis a vyrezávanie štruktúry proti surovému obrazu disku (docker_host_raw.img):

1. Pre databázy SQLite3 (.sqlite, .db - napr. Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Každá databáza SQLite3 začína nezameniteľnou 16-bajtovou hlavičkou ASCII v byte 0 svojej prvej 4 kilobajtovej stránky: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0") a ukladá presnú veľkosť stránky databázy (Bytes 16..17, zvyčajne 4096) a celková veľkosť databázy v stránkach (Bytes 28..31, big-endian 32-bitové celé číslo) priamo v tej istej hlavičke.
2. Bežať PhotoRec s [File Opt] -> [x] sqlite povolené, alebo skenujte oddiel priamo pomocou grep -ab "SQLite format 3" nájsť presný bajtový offset vášho odstráneného súboru SQLite a extrahovať ho pomocou dd:

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

   Po extrakcii spustite sqlite3 carved.db ".recover" | sqlite3 repaired.db zrekonštruovať každú neporušenú listovú stránku B-stromu.

1. Pre MySQL / MariaDB InnoDB (.ibd tabuľkové súbory): Každý InnoDB .ibd tabuľka pozostáva zo sekvenčných 16 KB (16,384 byte) stránky obsahujúce FIL_PAGE_INDEX (0x45BF) hlavička a jedinečná tabuľka space_id. Použite Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) súprava nástrojov na skenovanie /dev/nvme0n1p1 pre všetkých 16 KB Indexové stránky InnoDB a výpis každého riadku priamo do súborov TSV/SQL na opätovný import.
2. Pre súbory haldy PostgreSQL ($PGDATA/base/<db_oid>/<relfilenode>): PostgreSQL ukladá každú tabuľku ako súvislú 8 KB (8,192 byte) haldové stránky obsahujúce PageHeaderData (pd_lower, pd_upper, pd_special). Použiť pg_filedump alebo pglazarus / pdu na skenovanie nepridelených oblastí disku 8 KB stránky, ktoré sa zhodujú s rozložením stĺpcov v tabuľke (HeapTupleHeaderData) a zrekonštruujte riadky.

Fáza 4: Kubernetes PVC, PV a etcd Snímka núdzového zotavenia¶

V Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), náhodným odstránením PersistentVolumeClaim (kubectl delete pvc), StatefulSet alebo celý priestor názvov (kubectl delete ns prod) má veľmi odlišnú architektúru ako samostatný Docker.

Scenár A: Ukazuje sa PVC Terminating (The Finalizer Lifesaver)¶

Spustiť:

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

Scenár B: PVC bolo vymazané a kubectl get pv zobrazuje PersistentVolume v Released štát (ReclaimPolicy: Retain)¶

Spustiť:

kubectl get pv

Ako urobiť a Released PV Available opäť za 10 sekúnd s nulovou stratou údajov: 1. Upravte objekt PersistentVolume a odstráňte objekt spec.claimRef blokovať:

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

Scenár C: Obnovenie vymazaného stavu klastra Kubernetes zo súboru etcd snímka (etcdctl snapshot restore)¶

Čo keby niekto bežal kubectl delete namespace prod alebo helm uninstall a vymazali 200 Kubernetes manifestov, tajomstiev, ConfigMaps a definícií PV na samostatne spravovanom kubeadm, k3s, alebo RKE2 riadiace lietadlo?

1. ** Nájdite svoje najnovšie etcd snímka** (predvolene v /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/alebo podľa vášho plánu /var/backups/etcd/snapshot.db).
2. Pred dotykom aktívneho klastra overte integritu snímky:

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

3. Prestaň kube-apiserver a etcd na uzloch riadiacej roviny:
4. dňa kubeadm (statické moduly): Pohyb /etc/kubernetes/manifests/kube-apiserver.yaml a /etc/kubernetes/manifests/etcd.yaml dočasne na /root/manifests_hold/ tak kubelet zastaví oba kontajnery čisto a potom zacúva /var/lib/etcd do /var/lib/etcd.bak.
5. dňa k3s: Utekaj sudo systemctl stop k3s a sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** Obnovte etcd dátový adresár zapnutý 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. Pohybujte sa etcd.yaml a kube-apiserver.yaml späť do /etc/kubernetes/manifests/. Do 30 sekúnd, kube-apiserver sa znova pripojí k obnovenému etcd store a každý odstránený objekt Namespace, Secret, ConfigMap a PersistentVolume sa znova objaví.

Fáza 5: Posilnenie zväzkov Docker a Kubernetes proti náhodnému vymazaniu¶

Po obnovení vašej produkčnej databázy implementujte tieto štyri architektonické ochranné zábradlia, aby jediný preklep CLI už nikdy nemohol odstrániť aktívny zväzok:

• Zmeniť každý produkčný Kubernetes StorageClass od reclaimPolicy: Delete do reclaimPolicy: Retain: V predvolenom nastavení sú vstavané cloud StorageClasses (gp2, gp3, standard-rwo) predvolene reclaimPolicy: Delete, čo znamená, že odstránením PVC sa zničí cloudový disk. Vytvorte a StorageClass s reclaimPolicy: Retain (alebo opravte existujúce PV pomocou kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'), takže odstránením PVC alebo Namespace sa nikdy neodstráni základný blok bloku.
• Povolenie koša AWS EBS / plánov snímok GCP / Velero so snímkami CSI: Povolenie koša AWS EBS uchováva akýkoľvek odstránený zväzok EBS na 7 až 30 dní, aj keď vodič CSI zavolá DeleteVolume.
• Nikdy nepoužívajte docker system prune --volumes v automatických čistiacich skriptoch alebo spúšťačoch CI/CD: Ak kontajner produkčnej databázy krátko zlyhá (Exited (1)) presne v momente spustenia úlohy cron docker system prune -a --volumes -f, Docker považuje svoje anonymné zväzky za „nepoužité“ a natrvalo ich vymaže. Strip --volumes zo všetkých čistiacich skriptov.
• Použite explicitné pripojenia hostiteľskej väzby (/srv/prod_data/postgres:/var/lib/postgresql/data) alebo externé spravované databázy pre stavové produkčné úlohy: Na rozdiel od /var/lib/docker/volumes/, hostiteľské adresáre na pripojenie na väzbu vonku /var/lib/docker/ sa ich nikdy nedotkne docker compose down -v, docker volume rm, alebo docker system prune --volumes.

Regionálne tiesňové čísla a protokoly agentúr¶

Keď vymazanie kontajnera alebo úložiska Kubernetes ovplyvní nemocničné klinické operácie, odoslanie verejnej bezpečnosti alebo regulované osobné údaje, okamžite eskalujte:

• Spojené štáty a Kanada: Vytočiť 911 ak zlyhanie klastra kontajnerov zakáže klinické monitorovanie pacienta, systémy EHR alebo núdzové odoslanie. Nahláste vymazanie infraštruktúry kontajnerov alebo kybernetické incidenty CISA (1-844-Say-CISA / cisa.gov/report) alebo Kanadské centrum pre kybernetickú bezpečnosť (1-833-CYBER-88).
• Spojené kráľovstvo: Vytočiť 999 v prípade ohrozenia života alebo kritickej infraštruktúry NHS. Podľa GDPR Spojeného kráľovstva si trvalé zničenie alebo strata dostupnosti osobných údajov bez obnoviteľnej zálohy vyžaduje vyhodnotenie 72-hodinového oznámenia o porušení ICO (0303 123 1113).
• Európska únia: Vytočiť 112 vo všetkých členských štátoch EÚ. Subjekty podľa smernice NIS2 musia svojmu národnému CSIRT predložiť včasné varovanie do 24 hodín od vážneho výpadku služby a trvalá strata osobných údajov spustí článok 33 GDPR hlásenie do 72 hodín.
• Austrália a Nový Zéland: Vytočiť 000 v Austrálii alebo 111 na Novom Zélande; hlásiť incidenty kritickej infraštruktúry ACSC (1300 CYBER1).
• India a Ázia a Tichomorie: Vytočiť 112 v Indii pre núdzovú reakciu; nahlásiť bezpečnostné incidenty cloudu alebo kontajnerov na CERT-In (incident@cert-in.org.in) v rámci povinného 6-hodinového okna.

Často kladené otázky¶

robí docker compose down -v odstrániť pripojenia hostiteľských väzieb (./data:/var/lib/mysql) alebo len zväzky Named a Anonymous Docker?¶

`docker compose down -v` LEN vymaže pomenované zväzky deklarované v `volumes:` časť `docker-compose.yml` a Anonymné zväzky pripojené ku kontajnerom; to nikdy vymaže súbory v pripojení hostiteľa (ako napr `- /opt/mysql_data:/var/lib/mysql` alebo `- ./postgres_data:/var/lib/postgresql/data`). Ak váš komponovaný súbor používal cestu hostiteľa začínajúcu na `/` alebo `./`, skontrolujte tento priečinok na hostiteľovi práve teraz: vaše súbory sú stále 100 percent neporušené.

Prečo áno docker system prune --volumes odstrániť objem mojej databázy, keď som zastavil kontajner iba na 2 minúty, aby som aktualizoval premennú prostredia?¶

Pozorne čakajte na rozlíšenie medzi `docker stop` a `docker rm`: ak je kontajner iba `Stopped / Exited` (viditeľné v `docker ps -a`), `docker system prune --volumes` robí nie odstrániť jeho zväzky, pretože zastavený kontajner na ne stále odkazuje. Ak ste však bežali `docker rm ` (na opätovné vytvorenie kontajnera s novými vlajkami) alebo ak ste prešli `docker system prune -a --volumes` (ktorý najskôr odstráni všetky zastavené kontajnery a potom vymaže všetky objemy, ktoré už nie sú pripojené k žiadnemu kontajneru), objem „visel“ v milisekunde, kedy bola zastavená nádoba odstránená a ihneď potom bol vymazaný.

Môžem obnoviť odstránený zväzok Docker v Docker Desktop na Macu (Apple Silicon / Intel) alebo Windows (WSL2)?¶

Áno, ak okamžite ukončíte Docker Desktop, virtuálny počítač sa zastaví `fstrim` proti virtuálnemu disku. V systéme MacOS Docker ukladá všetky zväzky systému Linux vo vnútri `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; na Windows WSL2, vnútri `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Skopírujte to `.raw` alebo `.vhdx` súbor okamžite na externý SSD, pripojte ho len na čítanie v systéme Linux (pomocou `losetup -Pr` pre `.raw` alebo `qemu-nbd -r` pre `.vhdx`), a bežte `ext4magic` alebo `PhotoRec` proti virtuálnemu `ext4` priečka vo vnútri.

Čo keby som odstránil Kubernetes StatefulSet s kubectl delete statefulset postgres? Odstránilo to aj moje PVC?¶

Nie. V predvolenom nastavení v Kubernetes (pokiaľ `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` bol explicitne nakonfigurovaný na Kubernetes 1.27+), beží `kubectl delete statefulset` vymaže ovládač StatefulSet a jeho moduly, opustenie všetkých `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) a ich základné údaje sú 100 percent neporušené. Jednoducho znova použite svoj `StatefulSet` YAML manifest s rovnakým názvom a `volumeClaimTemplates`a nové moduly sa automaticky znova pripoja k existujúcim `data-postgres-0` PVC.

Ako získam prístup k súborom v Dockeri overlay2 adresár, keď sa kontajner odmietne spustiť (CrashLoopBackOff / Exited (1))?¶

Neodstraňujte poškodený kontajner. Pokiaľ zastavený kontajner stále existuje v `docker ps -a`, jeho zapisovateľná vrstva a zväzky sú na disku úplne nedotknuté. Súbory môžete kopírovať priamo zo zastaveného kontajnera pomocou `docker cp :/var/lib/postgresql/data /root/rescued_data`alebo nájdite jeho presného hostiteľa `overlay2` cesta behom `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` a čítanie tohto adresára priamo ako `root`.

Čo ak niekto odstránil Kubernetes Namespace (kubectl delete ns prod) a všetky PVC mali reclaimPolicy: Delete na AWS EBS alebo GCP?¶

Ak cloudový ovládač CSI (`ebs.csi.aws.com` alebo `pd.csi.storage.gke.io`) už vykonaný `DeleteVolume` pretože `reclaimPolicy` bol `Delete`, okamžite skontrolujte tri bezpečnostné siete na úrovni cloudu: (1) skontrolujte **Kôš AWS pre zväzky EBS** v konzole AWS EC2 (ak bolo na účte/značkách aktívne pravidlo uchovávania, odstránený zväzok EBS sa nachádza v koši a možno ho obnoviť jedným kliknutím); (2) skontrolujte **Zálohovanie AWS / DLM / Plány snímok GCP**, kde nájdete najaktuálnejšiu snímku automatického zväzku; a (3) skontrolujte, či vaša databáza streamovala WAL/binlogy (`WAL-G`, `pgBackRest`, `Litestream`) do vedra S3/GCS.

Súvisiaci sprievodcovia¶

• Disk servera je zaplnený na 100 % (0 bajtov voľných): nafúknutie denníka databázy WAL, poškodený B-strom a obnova s nulovým priestorom
• Náhodné rm -rf alebo Shift+Delete v systéme Linux, macOS alebo Windows: okamžité opätovné pripojenie iba na čítanie a vyrezávanie inode
• Virtuálny stroj VMDK, VHDX a qcow2 snapshot reťazové poškodenie a záchrana hypervízora
• Náhodné odovzdanie Git kľúčov AWS, súboru .env alebo súkromného kľúča SSH do verejného úložiska GitHub
• Kríza webhostingu, migrácia a obnovenie zálohy
• Počítačové zálohy, stratégia 3-2-1 a obnova po havárii
• Tiesňové čísla podľa krajiny

Zdroje a oficiálne pokyny¶

• Oficiálna dokumentácia Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Ochrana pri používaní úložného objektu (kubernetes.io/pvc-protection Finalizátori), Reclaiming PersistentVolumes (Retain vs. Delete) a Prevádzkové etcd Klastre pre Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Správa údajov v Docker: Zväzky, Pripojenia väzby, overlay2 Architektúra ovládačov úložného priestoru a referencia Prune.
• Organizácia Linuxového jadra (kernel.org): * /proc Súborový systém (procfs Otvorte File Descriptor Recovery cez /proc/<pid>/fd/) a Ext4 Journal Specification*.
• ext4magic Projektová dokumentácia (ext4magic.sourceforge.net): Forenzné obnovenie inode a žurnálových transakcií na súborových systémoch Ext3/Ext4.
• Národný inštitút pre štandardy a technológie (NIST) (Spojené štáty americké): Špeciálna publikácia 800-190: Application Container Security Guide & Incident Recovery.