Volum de producció de Docker o Kubernetes suprimit: rescatant docker system prune --volumes, overlay2 Inodes, i etcd Imatges instantànies¶

Córrer docker compose down -v, docker system prune -a --volumes, docker volume rm, o kubectl delete pvc a la pestanya de terminal incorrecta en producció és una de les maneres més ràpides d'esborrar un volum de base de dades PostgreSQL, MySQL, MariaDB, Redis, MongoDB o SQLite en directe. A diferència de les instantànies de màquines virtuals al núvol que es mouen a una paperera de reciclatge de 7 dies, el controlador de volum local de Docker (/var/lib/docker/volumes/<name>/_data) i Kubernetes local-path / hostPath els proveïdors emeten immediatament l'estàndard POSIX unlink() i rmdir() crida directament contra el sistema de fitxers host Linux subjacent (ext4, XFS, o Btrfs). Cada escriptura que es produeix en aquest amfitrió Linux després d'acabar l'ordre pot sobreescriure els blocs de base de dades alliberats al disc. Si el disc del servidor s'ha omplert al 100 per cent (0 bytes free) abans que algú corria docker system prune --volumes en pànic, consultar disc del servidor 100% ple, inflor de registre WAL de la base de dades i recuperació d'espai zero; per a les supressions de fitxers Linux sense metall fora dels contenidors, vegeu accidental rm -rf o Shift-Delete a ext4, XFS, APFS i NTFS: remuntar només de lectura i tallar inode i màquina virtual VMDK, VHDX i qcow2 corrupció de la cadena d'instantànies i rescat d'hipervisor. Si aquesta interrupció de la producció afecta l'atenció al pacient de l'hospital, l'enviament d'emergències o els sistemes de seguretat d'utilitat pública, truqueu al vostre número d'emergència local (911 als Estats Units i al Canadà, 112 a tota la Unió Europea, 999 al Regne Unit) o consulteu el nostre directori de números d'emergència.

Fes això ara¶

1. ** NO córrer docker compose up -d, systemctl restart docker, o torneu a desplegar el pod de Kubernetes**: en tornar a crear el contenidor o en reiniciar el dimoni Docker s'escriuen megabytes de nous overlay2 metadades, registres JSON del contenidor i fitxers de base de dades buits recentment inicialitzats (initdb) directament sobre l'exacte ext4 o XFS blocs on el volum suprimit estava assegut fa segons.
2. Comproveu d'aquí a 5 segons si el procés del contenidor (postgres, mysqld, redis-server, node, python) encara s'està executant a la memòria (ps aux i sudo lsof +L1): si algú ha suprimit fitxers dins d'un volum muntat o ha desenllaçat un volum anònim mentre el contenidor encara s'està executant, el nucli de Linux manté viu al disc el 100 per cent dels fitxers de base de dades desenllaçats sempre que l'identificador de procés amfitrió del contenidor (PID) conté un descriptor de fitxer obert (FD). Podeu copiar aquests fitxers directament /proc/<PID>/fd/ o /proc/<PID>/root/ amb zero pèrdua de dades abans que el contenidor s'aturi.
3. Si el contenidor ja està aturat i el volum s'ha suprimit (docker compose down -v o docker system prune --volumes), congela el disc amfitrió escriu immediatament: Atureu el dimoni Docker (sudo systemctl stop docker.socket docker.service containerd) de manera que els contenidors en segon pla i els controls de salut deixen d'escriure registres /var/lib/docker, després o bé tornar a muntar /var/lib/docker (o l'arrel / partició) només de lectura (sudo mount -o remount,ro /) o feu una instantània immediata del volum del núvol a nivell de bloc (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) abans de tocar res.
4. Si esteu a Kubernetes (kubectl delete pvc o kubectl delete namespace), comproveu el volum persistent (PV) ReclaimPolicy (kubectl get pv) immediatament:
5. Si el PV tenia persistentVolumeReclaimPolicy: Retain, les teves dades no s'eliminen: el PV simplement traslladat a Released estat i el vostre disc al núvol (EBS, Azure Disk, Ceph RBD, NFS) està 100 per cent intacte.
6. Encara que kubectl delete pvc està encallat a Terminating, Kubernetes Finalitzadors (kubernetes.io/pvc-protection) impedeix que el controlador CSI suprimeixi l'emmagatzematge subjacent sempre que qualsevol pod encara faci referència a aquest PVC. No suprimiu el pod fins que no copieu les dades del pod en execució.
7. Imatge de la partició de blocs subjacent (dd / ddrescue a través de SSH) a un disc extern o a un volum de núvol separat abans d'executar-se ext4magic, extundelete, o PhotoRec: No executeu mai els talladors de fitxers que escriguin fitxers de sortida a la mateixa partició de disc de la qual us esteu recuperant /var/lib/docker/volumes.
8. Per a l'estat del clúster de Kubernetes danyat o esborrat accidentalment (kubectl delete crd / namespace), parar kube-apiserver i restaura el teu últim etcd instantània (etcdctl snapshot restore): si el clúster està en etcd es va esborrar mentre els volums d'emmagatzematge al núvol subjacents encara existeixen, restaurant-se etcd recupera tot PV, PVC, Secret, i ConfigMap objectes simultàniament.

Arbre de decisió: volum Docker suprimit, overlay2 capa o triatge de PVC de Kubernetes¶

Utilitzeu aquest diagrama de flux per triar la ruta de recuperació de pèrdua zero més ràpida en funció de si el procés del contenidor encara està viu, si el volum estava recolzat per un disc local o un emmagatzematge CSI al núvol i quin sistema de fitxers allotja /var/lib/docker:

flowchart TD
    Start["Falten dades de producció després de l'ordre d'eliminació de Docker o Kubernetes"] --> WhichEnv{"Quina plataforma i quina ordre van provocar la pèrdua?"}

    WhichEnv -->|"Docker: el contenidor encara funciona (fitxers desenllaçats dins del volum/contenidor)"| ProcRescue["Rescatar els descriptors de fitxers sense enllaçar oberts mitjançant sudo lsof +L1 i /proc/PID/fd/N o /proc/PID/root/"]

    WhichEnv -->|"Docker: contenidor aturat i volum suprimit (composar -v / podar --volums)"| StopDocker["Executeu immediatament: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl suprimeix pvc / pv / statefulset / namespace"| K8sCheck{"El pod segueix funcionant O s'ha enganxat el PVC en acabar?"}

    K8sCheck -->|"Sí: el pod encara s'està executant (eliminació de CSI que bloqueja el finalitzador)"| K8sExec["NO suprimiu el pod -> Executeu kubectl exec / pg_dump / tar sobre stdout al disc local immediatament"]
    K8sCheck -->|"No: Pod Gone -> Comprova kubectl get pv"| ReclaimCheck{"Què va ser PV ReclaimPolicy?"}

    ReclaimCheck -->|"Retenir (estat PV = llançat)"| ClearClaimRef["Dades 100% intactes -> Edita PV per eliminar spec.claimRef.uid -> Torna a vincular-se al nou PVC"]
    ReclaimCheck -->|"Suprimeix (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Volum CSI al núvol o disc d'amfitrió local?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Comproveu la paperera de reciclatge de Cloud Console / instantànies automatitzades d'EBS / Ceph RBD Trash (rbd trash ls)"]
    CloudOrLocal -->|"Disc del node local (camí local/camí de host)"| StopDocker

    StopDocker --> RemountRO["Remunta la partició de l'amfitrió només de lectura (mount -o remount,ro) O transmet la imatge del bloc a través de SSH"]
    RemountRO --> HostFS{"Quin sistema de fitxers allotja /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Utilitzeu debugfs / ext4magic Journal Inode Transaction Rollback (-a marca de temps)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Utilitzeu Btrfs Roots / xfs_irecover / Custom Signature Carving per a SQLite, Postgres Heap o InnoDB .ibd"]

Fase 1: com Docker i Kubernetes suprimeixen realment els volums del disc¶

Abans d'executar qualsevol ordre de recuperació, enteneu on vivien físicament les vostres dades a l'amfitrió Linux i què va tocar realment l'ordre de supressió:

Fase 2: rescatar fitxers de base de dades oberts d'un contenidor que encara està en execució (/proc/<pid>/fd/)¶

Espereu: el contenidor segueix funcionant ara mateix? Sovint, un enginyer executa un script de migració d'aplicacions, un treball cron de neteja o un manual rm -rf /var/lib/postgresql/data/* o rm /app/data/production.sqlite3 dins d'un contenidor en execució o elimina la carpeta de muntatge d'enllaç de l'amfitrió subjacent /opt/app/data mentre que el propi recipient (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) està encara en funcionament.

A Linux, un fitxer no s'elimina del disc quan rm o unlink() es diu. Els seus blocs de disc i inode romanen 100 per cent assignats i llegibles fins a l'últim procés que conté un descriptor de fitxer obert (FD) a aquest inode el tanca o surt.

Pas 1: cerqueu l'identificador de procés de l'amfitrió (PID) del procés del contenidor¶

Al node de l'amfitrió de Linux (no dins del contenidor), cerqueu l'amfitrió PID de la vostra base de dades o procés de sol·licitud:

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)

Pas 2: copieu els fitxers de la base de dades desenllaçats directament /proc/<PID>/fd/¶

No atureu ni reinicieu el contenidor. Mentre el procés encara s'està executant, copieu els descriptors del fitxer en brut directament a una carpeta segura del vostre amfitrió:

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

Pas 3: encara millor: executeu un abocament lògic en directe (pg_dump / mysqldump / .backup) abans que el contenidor tanqui els FD¶

Si postgres o mysqld encara s'està executant amb els seus fitxers de dades oberts a la memòria i /proc/<PID>/fd/, proveu d'executar primer un abocament lògic en directe sobre el sòcol Unix existent o la connexió 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

Fase 3: recuperació d'un volum Docker suprimit activat ext4 o XFS després de parar el contenidor¶

Què passa si corries docker compose down -v o docker system prune --volumes, de manera que el contenidor està ja aturat i tot /proc/<pid>/fd/ els descriptors estan tancats? Ara esteu en una carrera contra les escriptures de disc de fons a l'amfitrió Linux.

Pas 1: Congeleu el sistema de fitxers host de Linux en 10 segons¶

1. Atura Docker, containerd, kubelet i cron immediatament, de manera que cap contenidor, control de salut o rotador de registre escrigui un altre byte a /var/lib/docker:

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

2. Comproveu quin dispositiu de bloc i sistema de fitxers conté /var/lib/docker:

   df -Th /var/lib/docker
   

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

3. ** Torneu a muntar la partició de només lectura (o transmeteu una imatge de partició en brut a través de SSH a una altra màquina)**:
4. Si /var/lib/docker es troba a la seva pròpia partició dedicada o volum LVM (per exemple /dev/nvme0n1p2 o /dev/mapper/vg0-docker), torneu-lo a muntar de només lectura immediatament:

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

5. Si /var/lib/docker està a l'arrel / partició (/), proveu de forçar la partició arrel de només lectura mitjançant el disparador Magic SysRq del nucli (echo u | sudo tee /proc/sysrq-trigger) o sudo mount -o remount,ro /.
6. Si esteu en un VPS al núvol (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): aneu immediatament a la vostra consola web al núvol i feu clic a Crea una instantània al volum de blocs del servidor (o transmeteu el dispositiu de blocs en brut per SSH a un segon servidor: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Pas 2: comproveu si les vostres dades encara es troben en un ALTRE volum sense podar o overlay2 capa¶

Abans de tallar blocs de disc no assignats, verifiqueu que la vostra base de dades no s'hagi emmagatzemat en un muntatge d'enllaç o un volum amb un nom diferent que hagi sobreviscut:

# 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

Pas 3: recuperació dels directoris de volums de Docker desenllaçats activats ext4 utilitzant el ext4 Diari (ext4magic i debugfs)¶

Quan docker volume rm elimina /var/lib/docker/volumes/<vol_name>/_data en un ext4 sistema de fitxers, ext4 elimina els zeros dels punters de bloc directe (i_block / arrel de l'arbre d'extensió) a la taula d'inodes en viu. Tanmateix, el ext4 diari (inode <8>, normalment 128 MB a 1024 MB buffer d'anell circular) encara conté còpies històriques de les taules d'inodes exactes i dels blocs de directoris just abans docker compose down -v va ser executat.

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

Corre ext4magic contra la vostra partició de només lectura (o el .img còpia de la instantània en un segon servidor), especificant una marca de temps (-a) des de 5 minuts abans vas córrer docker compose down -v o 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

Pas 4: tallar fitxers SQLite, PostgreSQL o MySQL InnoDB en brut quan la revista s'hagi embolicat (XFS o ext4)¶

Si l'amfitrió utilitza XFS o si el ext4 diari ja embolicat sobre els punters de l'inode, utilitzeu la signatura i l'estructura tallada contra la imatge de disc en brut (docker_host_raw.img):

1. Per a bases de dades SQLite3 (.sqlite, .db - p. ex., Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Cada base de dades SQLite3 comença amb una capçalera ASCII inconfusible de 16 bytes al byte 0 de la seva primera pàgina de 4 kilobytes: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), i emmagatzema la mida exacta de la pàgina de la base de dades (Bytes 16..17, normalment 4096) i la mida total de la base de dades en pàgines (Bytes 28..31, sencer big-endian de 32 bits) just dins de la mateixa capçalera.
2. Corre PhotoRec amb [File Opt] -> [x] sqlite habilitat, o escanejar la partició directament amb grep -ab "SQLite format 3" per trobar el desplaçament exacte de bytes del fitxer SQLite eliminat i extreure-lo dd:

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

   Un cop extret, córrer sqlite3 carved.db ".recover" | sqlite3 repaired.db per reconstruir cada pàgina de fulla de l'arbre B intacta.

1. Per a MySQL / MariaDB InnoDB (.ibd fitxers de taula): Cada InnoDB .ibd taula consta de seqüencials 16 KB (16,384 byte) pàgines que contenen FIL_PAGE_INDEX (0x45BF) i l'únic de la taula space_id. Utilitzeu el Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) conjunt d'eines per escanejar /dev/nvme0n1p1 per a tots 16 KB Pàgines d'índex d'InnoDB i bolqueu cada fila directament als fitxers TSV/SQL per tornar-los a importar.
2. Per a fitxers Heap PostgreSQL ($PGDATA/base/<db_oid>/<relfilenode>)*: PostgreSQL emmagatzema cada taula com a contigua 8 KB (8,192 byte) munt de pàgines que contenen PageHeaderData (pd_lower, pd_upper, pd_special). Utilitza pg_filedump o pglazarus / pdu per escanejar regions de disc no assignades 8 KB pàgines que coincideixen amb el disseny de tuple de columnes de la taula (HeapTupleHeaderData) i reconstrueix les files.

Fase 4: Kubernetes PVC, PV i etcd Recuperació d'emergència instantània¶

A Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), eliminant accidentalment un PersistentVolumeClaim (kubectl delete pvc), un StatefulSet o un espai de noms sencer (kubectl delete ns prod) segueix una arquitectura molt diferent a la de Docker autònom.

Escenari A: es veu el PVC Terminating (The Finalizer Lifesaver)¶

Executar:

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

Escenari B: es va suprimir el PVC i kubectl get pv mostra el volum persistent en Released estat (ReclaimPolicy: Retain)¶

Executar:

kubectl get pv

Com fer a Released PV Available de nou en 10 segons sense pèrdua de dades: 1. Editeu l'objecte PersistentVolume i suprimiu-lo spec.claimRef bloc:

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

Escenari C: restauració d'un estat de clúster Kubernetes esborrat des d'un etcd instantània (etcdctl snapshot restore)¶

I si algú corria kubectl delete namespace prod o helm uninstall i va eliminar 200 manifests de Kubernetes, Secrets, ConfigMaps i definicions PV en un sistema autogestionat kubeadm, k3s, o RKE2 avió de control?

1. Busca el teu últim etcd instantània (per defecte a /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, o el teu programat /var/backups/etcd/snapshot.db).
2. Verifiqueu la integritat de la instantània abans de tocar el clúster en directe:

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

3. ** Atureu-vos kube-apiserver i etcd al node(s) del pla de control**:
4. En kubeadm (beines estàtiques): Moure's /etc/kubernetes/manifests/kube-apiserver.yaml i /etc/kubernetes/manifests/etcd.yaml temporalment a /root/manifests_hold/ doncs kubelet atura els dos contenidors netament i després torna a fer una còpia de seguretat /var/lib/etcd a /var/lib/etcd.bak.
5. En k3s: Corre sudo systemctl stop k3s i sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. Restaurar el etcd directori de dades activat 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. Mou-te etcd.yaml i kube-apiserver.yaml torna a entrar /etc/kubernetes/manifests/. En 30 segons, kube-apiserver es torna a connectar amb el restaurat etcd emmagatzema i tots els objectes Namespace, Secret, ConfigMap i PersistentVolume suprimits reapareixen.

Fase 5: Enduriment dels volums de Docker i Kubernetes contra la supressió accidental¶

Un cop restaurada la vostra base de dades de producció, implementeu aquestes quatre baranes arquitectòniques de manera que un sol error tipogràfic de la CLI no pugui suprimir mai més un volum en directe:

• Canvia tots els Kubernetes de producció StorageClass des de reclaimPolicy: Delete a reclaimPolicy: Retain: Per defecte, StorageClasses al núvol integrat (gp2, gp3, standard-rwo) per defecte reclaimPolicy: Delete, és a dir, suprimir un PVC destrueix el disc del núvol. Crea un StorageClass amb reclaimPolicy: Retain (o pegats els PV existents amb kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') de manera que suprimir un PVC o un espai de noms mai se suprimeix el volum del bloc subjacent.
• Activa la Paperera de reciclatge d'AWS EBS/Programmes d'instantànies de GCP/Velero amb instantànies CSI: l'activació de la Paperera de reciclatge d'AWS EBS conserva qualsevol volum d'EBS suprimit durant 7 a 30 dies, fins i tot si el controlador CSI truca DeleteVolume.
• ** No utilitzeu mai docker system prune --volumes en scripts de neteja automatitzats o corredors CI/CD**: si un contenidor de base de dades de producció es bloqueja breument (Exited (1)) en el moment exacte en què s'executa un treball cron docker system prune -a --volumes -f, Docker considera els seus volums anònims "no utilitzats" i els suprimeix permanentment. Tira --volumes de tots els scripts de neteja.
• ** Utilitzeu muntatges d'enllaç d'amfitrió explícits (/srv/prod_data/postgres:/var/lib/postgresql/data) o bases de dades gestionades externes per a càrregues de treball de producció amb estat**: a diferència /var/lib/docker/volumes/, host de directoris de muntatge d'enllaç fora /var/lib/docker/ són mai tocats per docker compose down -v, docker volume rm, o docker system prune --volumes.

Números d'emergència regionals i protocols de l'agència¶

Quan la supressió d'un contenidor o d'emmagatzematge de Kubernetes afecta les operacions clíniques de l'hospital, l'enviament de seguretat pública o les dades personals regulades, escala immediatament:

• Estats Units i Canadà: marca 911 si una fallada del clúster de contenidors desactiva el seguiment clínic del pacient, els sistemes d'EHR o l'enviament d'emergència. Informeu d'esborrats d'infraestructura de contenidors maliciosos o incidents cibernètics a CISA (1-844-Say-CISA / cisa.gov/report) o el Centre Canadien per a la Ciberseguretat (1-833-CYBER-88).
• Regne Unit: marca 999 per amenaces a la vida o a la infraestructura crítica del NHS. Segons el RGPD del Regne Unit, la destrucció permanent o la pèrdua de disponibilitat de dades personals sense una còpia de seguretat recuperable requereix avaluar una notificació d'incompliment de 72 hores a l'ICO (0303 123 1113).
• Unió Europea: marca 112 a tots els estats membres de la UE. Les entitats sota la Directiva NIS2 han d'enviar un avís anticipat al seu CSIRT nacional en un termini de 24 hores després d'una interrupció greu del servei, i la pèrdua permanent de dades personals activa l'informe de l'article 33 del RGPD en un termini de 72 hores.
• Austràlia i Nova Zelanda: marca 000 a Austràlia o 111 a Nova Zelanda; informar d'incidències d'infraestructures crítiques a l'ACSC (1300 CYBER1).
• Índia i Àsia-Pacífic: marca 112 a l'Índia per a la resposta d'emergència; reporteu incidents de seguretat al núvol o als contenidors a CERT-In (incident@cert-in.org.in) dins del període obligatori de 6 hores.

Preguntes freqüents¶

Ho fa docker compose down -v suprimiu els muntatges d'enllaç de l'amfitrió (./data:/var/lib/mysql) o només volums Docker amb nom i anònim?¶

`docker compose down -v` NOMÉS elimina els volums amb nom declarats al `volumes:` secció de `docker-compose.yml` i volums anònims units als contenidors; això mai suprimeix fitxers dins d'un muntatge d'enllaç d'amfitrió (com ara `- /opt/mysql_data:/var/lib/mysql` o `- ./postgres_data:/var/lib/postgresql/data`). Si el vostre fitxer de redacció utilitzava una ruta d'amfitrió que començava per `/` o `./`, comproveu aquesta carpeta a l'amfitrió ara mateix: els vostres fitxers encara estan intactes al 100%.

Per què ho va fer docker system prune --volumes suprimir el volum de la meva base de dades quan només vaig aturar el contenidor durant 2 minuts per actualitzar una variable d'entorn?¶

Espereu amb cura la distinció entre `docker stop` i `docker rm`: si un contenidor és merament `Stopped / Exited` (visible a `docker ps -a`), `docker system prune --volumes` fa no suprimiu els seus volums perquè el contenidor aturat encara hi fa referència. Tanmateix, si vas córrer `docker rm ` (per recrear el contenidor amb banderes noves) o si heu passat `docker system prune -a --volumes` (que primer elimina tots els contenidors aturats i aleshores elimina tots els volums que ja no estan connectats a cap contenidor), el volum es va "penjar" el mil·lisegon que es va treure el contenidor aturat i es va netejar immediatament després.

Puc recuperar un volum de Docker suprimit dins de Docker Desktop en un Mac (Apple Silicon / Intel) o Windows (WSL2)?¶

Sí, si sortiu de Docker Desktop immediatament perquè la màquina virtual deixi de funcionar `fstrim` contra el disc virtual. A macOS, Docker emmagatzema tots els volums de Linux dins `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; a Windows WSL2, dins `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Copia això `.raw` o `.vhdx` fitxer a un SSD extern immediatament, adjunteu-lo de només lectura a Linux (utilitzant `losetup -Pr` per `.raw` o `qemu-nbd -r` per `.vhdx`), i córrer `ext4magic` o `PhotoRec` contra el virtual `ext4` partició a l'interior.

Què passa si suprimís un Kubernetes StatefulSet amb kubectl delete statefulset postgres? Això també ha suprimit els meus PVC?¶

No. Per defecte a Kubernetes (tret que `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` es va configurar explícitament a Kubernetes 1.27+), en execució `kubectl delete statefulset` elimina el controlador StatefulSet i els seus pods, deixant-ho tot `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) i les seves dades subjacents intactes al 100%.. Simplement torneu a aplicar el vostre `StatefulSet` Manifest YAML amb el mateix nom i `volumeClaimTemplates`, i els pods nous es tornaran a connectar automàticament als existents `data-postgres-0` PVC.

Com puc accedir als fitxers dins d'un Docker overlay2 directori quan el contenidor es nega a iniciar (CrashLoopBackOff / Exited (1))?¶

No suprimiu el contenidor bloquejat. Sempre que el contenidor aturat encara existeixi `docker ps -a`, la seva capa d'escriptura i els muntatges de volum estan completament intactes al disc. Podeu copiar fitxers directament fora del contenidor aturat mitjançant `docker cp :/var/lib/postgresql/data /root/rescued_data`, o trobeu el seu amfitrió exacte `overlay2` camí corrent `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` i llegint aquest directori directament com `root`.

Què passa si algú esborra un Kubernetes? Namespace (kubectl delete ns prod) i tots els PVC tenien reclaimPolicy: Delete a AWS EBS o GCP?¶

Si el controlador CSI del núvol (`ebs.csi.aws.com` o `pd.csi.storage.gke.io`) ja executat `DeleteVolume` perquè `reclaimPolicy` era `Delete`, comproveu immediatament tres xarxes de seguretat a nivell de núvol: (1) comproveu **AWS Recycle Paper for EBS Volumes** a la consola AWS EC2 (si hi havia una regla de retenció activa al compte/etiquetes, el volum EBS suprimit es troba a la Paperera de reciclatge i es pot restaurar amb 1 clic); (2) comproveu **Còpia de seguretat d'AWS/DLM/Planificacions d'instantània de GCP** per obtenir la instantània de volum automatitzada més recent; i (3) comproveu si la vostra base de dades transmetia WAL/binlogs (`WAL-G`, `pgBackRest`, `Litestream`) a un cub S3/GCS.

Guies relacionades¶

• Disc del servidor 100% ple (0 bytes lliures): inflor de registre WAL de la base de dades, arbre B danyat i recuperació d'espai zero
• rm -rf o Maj+Suprimir accidental a Linux, macOS o Windows: remuntada immediata de només lectura i tallat d'inode
• Corrupció de la cadena d'instantànies de la màquina virtual VMDK, VHDX i qcow2 i rescat d'hipervisor
• Comissió Git accidental de claus AWS, fitxer .env o clau privada SSH al dipòsit públic de GitHub
• Crisi d'allotjament web, migració i restauració de còpies de seguretat
• Còpies de seguretat d'ordinadors, estratègia 3-2-1 i recuperació de desastres
• Números d'emergència per països

Fonts i orientació oficial¶

• Documentació oficial de Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Protecció d'objectes d'emmagatzematge en ús (kubernetes.io/pvc-protection Finalitzadors), Recuperació de volums persistents (Retain vs. Delete), i en funcionament etcd Clústers per a Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Gestiona les dades a Docker: volums, muntatges d'enllaç, overlay2 Arquitectura del controlador d'emmagatzematge i referència de Prune.
• L'organització del nucli de Linux (kernel.org): El /proc Sistema de fitxers (procfs Obriu la recuperació del descriptor de fitxers mitjançant /proc/<pid>/fd/) i Especificació del diari Ext4.
• ext4magic Documentació del projecte (ext4magic.sourceforge.net): Inode forense i recuperació de transaccions de diari en sistemes de fitxers Ext3/Ext4.
• Institut Nacional d'Estàndards i Tecnologia (NIST) (Estats Units): Publicació especial 800-190: Guia de seguretat de contenidors d'aplicacions i recuperació d'incidents.