Vëllimi i prodhimit të Docker ose Kubernetes u fshi: Shpëtimi docker system prune --volumes, overlay2 Inodes, dhe etcd Fotot e çastit¶

Vrapimi docker compose down -v, docker system prune -a --volumes, docker volume rm, ose kubectl delete pvc në skedën e gabuar të terminalit në prodhim është një nga mënyrat më të shpejta për të fshirë një vëllim të drejtpërdrejtë të bazës së të dhënave PostgreSQL, MySQL, MariaDB, Redis, MongoDB ose SQLite. Ndryshe nga fotografitë e makinës virtuale cloud që zhvendosen në një kosh riciklimi 7-ditor, drejtuesi lokal i volumit të Docker (/var/lib/docker/volumes/<name>/_data) dhe Kubernetes local-path / hostPath ofruesit lëshojnë menjëherë standardin POSIX unlink() dhe rmdir() bën thirrje direkt kundër sistemit themelor të skedarëve pritës Linux (ext4, XFS, ose Btrfs). Çdo shkrim që ndodh në atë host Linux pasi të përfundojë komanda mund të mbishkruajë blloqet e liruara të bazës së të dhënave në disk. Nëse disku i serverit tuaj është mbushur 100 përqind (0 bytes free) përpara se dikush të vraponte docker system prune --volumes në panik, konsultohuni disku i serverit 100% plot, fryrje e regjistrit të bazës së të dhënave WAL dhe rikuperim i hapësirës zero; për fshirjet e skedarëve Linux të zhveshur jashtë kontejnerëve, shih aksidentale rm -rf ose Shift-Delete në ext4, XFS, APFS dhe NTFS: rimontim vetëm për lexim dhe gdhendje inode dhe korrupsioni i zinxhirit të fotografive të çastit të makinës virtuale VMDK, VHDX dhe qcow2 dhe shpëtimi i hipervizorit. Nëse kjo ndërprerje e prodhimit ndikon në kujdesin e pacientit spitalor, dërgimin e urgjencës ose sistemet e sigurisë së shërbimeve publike, telefononi numrin tuaj të urgjencës lokale (911 në Shtetet e Bashkuara dhe Kanada, 112 në të gjithë Bashkimin Evropian, 999 në Mbretërinë e Bashkuar) ose kontrolloni drejtorinë tonë të numrat e urgjencës.

Bëje këtë tani¶

1. ** MOS vraponi docker compose up -d, systemctl restart docker, ose rishpërndani podin e Kubernetes**: Rikrijimi i kontejnerit ose rinisja e demonit Docker shkruan megabajt të reja overlay2 meta të dhënat, regjistrat JSON të kontejnerit dhe skedarët bosh të bazës së të dhënave të sapo inicializuara (initdb) direkt mbi ekzakt ext4 ose XFS blloqe ku volumi juaj i fshirë ishte ulur disa sekonda më parë.
2. **Kontrollo për 5 sekonda nëse procesi i kontejnerit (postgres, mysqld, redis-server, node, python) është ende në memorie (ps aux dhe sudo lsof +L1(PID) mban një përshkrues skedari të hapur (FD). Ju mund t'i kopjoni ato skedarë drejtpërdrejt nga /proc/<PID>/fd/ ose /proc/<PID>/root/ me zero humbje të të dhënave përpara se kontejneri të ndalojë.
3. Nëse kontejneri është ndalur tashmë dhe vëllimi është fshirë (docker compose down -v ose docker system prune --volumes), ngrini diskun e hostit shkruan menjëherë: Ndalo daemonin Docker (sudo systemctl stop docker.socket docker.service containerd) kështu që kontejnerët e sfondit dhe kontrollet shëndetësore ndalojnë së shkruari regjistrat në /var/lib/docker, pastaj ose rimontohuni /var/lib/docker (ose rrënja / ndarje) vetëm për lexim (sudo mount -o remount,ro /) ose bëni një pamje të menjëhershme të volumit të resë në nivel blloku (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) përpara se të prekni ndonjë gjë.
4. **Nëse jeni në Kubernetes (kubectl delete pvc ose kubectl delete namespace), kontrolloni Vëllimin e Përhershëm (PV) ReclaimPolicy (kubectl get pv) menjëherë **:
5. Nëse PV kishte persistentVolumeReclaimPolicy: Retain, të dhënat tuaja nuk fshihen: the PV thjesht u zhvendos në Released statusi dhe disku juaj cloud (EBS, Azure Disk, Ceph RBD, NFS) është 100 për qind i paprekur.
6. Edhe nëse kubectl delete pvc është bllokuar në Terminating, Kubernetes Finalizuesit (kubernetes.io/pvc-protection) bllokon drejtuesin e CSI-së nga fshirja e hapësirës ruajtëse bazë për sa kohë që çdo Pod ende i referohet atij PVC. Mos e fshini Pod-in derisa të kopjoni të dhënat nga Pod-i që funksionon.
7. Imagjinoni ndarjen e bllokut themelor (dd / ddrescue mbi SSH) në një disk të jashtëm ose vëllim të veçantë të resë kompjuterike përpara se të ekzekutohet ext4magic, extundelete, ose PhotoRec: Asnjëherë mos ekzekutoni skedarë gdhendur që shkruajnë skedarë dalës në të njëjtën ndarje të diskut nga e cila po rikuperoni /var/lib/docker/volumes.
8. Për gjendjen e grupit Kubernetes të korruptuar ose të fshirë aksidentalisht (kubectl delete crd / namespace), ndalo kube-apiserver dhe rivendosni më të fundit etcd foto e çastit (etcdctl snapshot restore): Nëse gjendja e grupimit në etcd u fshi ndërsa vëllimet themelore të ruajtjes së resë kompjuterike ekzistojnë ende, duke u rivendosur etcd rikuperon të gjitha PV, PVC, Secret, dhe ConfigMap objekte në të njëjtën kohë.

Pema e vendimit: vëllimi Docker i fshirë, overlay2 shtresa, ose Kubernetes PVC triazh¶

Përdorni këtë diagram për të zgjedhur shtegun më të shpejtë të rikuperimit me humbje zero bazuar në faktin nëse procesi i kontejnerit është ende i gjallë, nëse vëllimi është mbështetur nga disku lokal ose ruajtja CSI në renë kompjuterike dhe cili sistem skedar pret /var/lib/docker:

flowchart TD
    Start["Mungojnë të dhënat e prodhimit pas komandës së fshirjes së Docker ose Kubernetes"] --> WhichEnv{"Cila platformë dhe komanda shkaktoi humbjen?"}

    WhichEnv -->|"Docker: kontejneri ende në punë (skedarët e palidhur brenda vëllimit/kontejnerit)"| ProcRescue["Shpëtoni përshkruesit e skedarëve të palidhur të hapur përmes sudo lsof +L1 dhe /proc/PID/fd/N ose /proc/PID/root/"]

    WhichEnv -->|"Docker: Kontejneri u ndal dhe vëllimi u fshi (kompozoni poshtë -v / krasitni --vëllimet)"| StopDocker["Ekzekuto menjëherë: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl fshij pvc / pv / statusfulset / hapësira e emrave"| K8sCheck{"Pod ende funksionon APO PVC është i mbërthyer në përfundim?"}

    K8sCheck -->|"Po: Pod ende po funksionon (Finalizer bllokon fshirjen e CSI)"| K8sExec["MOS Fshi Pod -> Ekzekuto kubectl exec / pg_dump / tar mbi stdout në Disk Lokal Menjëherë"]
    K8sCheck -->|"Jo: Pod Gone -> Kontrollo kubectl get pv"| ReclaimCheck{"Cila ishte politika e rikthimit të PV?"}

    ReclaimCheck -->|"Ruaj (Statusi PV = i lëshuar)"| ClearClaimRef["100% të dhëna të paprekura -> Ndrysho PV-në për të hequr spec.claimRef.uid -> Rilidhuni me PVC të re"]
    ReclaimCheck -->|"Fshi (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Vëllimi i CSI në renë kompjuterike apo disku i pritësit lokal?"}

    CloudOrLocal -->|"CSI Cloud (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Kontrollo koshin e riciklimit të konsolës së resë kompjuterike / Fotot e automatizuara të EBS / Plehrat e Ceph RBD (rbd plehra)"]
    CloudOrLocal -->|"Disku i nyjeve lokale (shtegu lokal/shtegu i hostit)"| StopDocker

    StopDocker --> RemountRO["Rimontoni ndarjen e hostit vetëm për lexim (montim -o rimontim,ro) OSE Transmetoni imazhin e bllokimit mbi SSH"]
    RemountRO --> HostFS{"Çfarë sistemi skedar pret /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Përdor korrigjimet / ext4magic Ditar Inode Rikthimi i transaksionit (-një vulë kohore)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Përdorni Btrfs Roots / xfs_irecover / Gdhendje e nënshkrimit të personalizuar për SQLite, Postgres Heap ose InnoDB .ibd"]

Faza 1: Si Docker dhe Kubernetes fshijnë në të vërtetë vëllimet në disk¶

Përpara se të ekzekutoni ndonjë komandë rikuperimi, kuptoni se ku jetonin fizikisht të dhënat tuaja në hostin Linux dhe çfarë preku në të vërtetë komanda e fshirjes:

Faza 2: Shpëtimi i skedarëve të hapur të bazës së të dhënave nga një kontejner që ende funksionon (/proc/<pid>/fd/)¶

Prisni: a po funksionon ende kontejneri për momentin? Shpesh, një inxhinier drejton një skript të migrimit të aplikacionit, një punë pastrimi të cron-it ose një manual rm -rf /var/lib/postgresql/data/* ose rm /app/data/production.sqlite3 brenda një kontejneri që funksionon, ose fshin dosjen bazë të lidhjes me montimin e hostit /opt/app/data ndërsa vetë kontejneri (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) është ende në funksion.

Në Linux, një skedar nuk fshihet nga disku kur rm ose unlink() quhet. Blloqet e diskut dhe inodi i tij mbeten 100 përqind të alokuara dhe të lexueshme deri në procesin e fundit që mban një përshkrues skedari të hapur (FD) në atë inode e mbyll atë ose del.

Hapi 1: Gjeni ID-në e procesit pritës (PID) të procesit të kontejnerit¶

Në nyjen pritës Linux (jo brenda kontejnerit), gjeni hostin PID e bazës së të dhënave ose procesit të aplikimit tuaj:

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)

Hapi 2: Kopjoni skedarët e palidhur të bazës së të dhënave direkt nga /proc/<PID>/fd/¶

Mos ndaloni ose rindizni kontejnerin. Ndërsa procesi është ende duke u ekzekutuar, kopjoni përshkruesit e skedarëve të papërpunuar drejtpërdrejt në një dosje të sigurt në hostin tuaj:

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

Hapi 3: Edhe më mirë: Drejtoni një hale logjike të drejtpërdrejtë (pg_dump / mysqldump / .backup) përpara se kontejneri të mbyllë FD-të¶

Nëse postgres ose mysqld është ende duke u ekzekutuar me skedarët e të dhënave të hapura në memorie dhe /proc/<PID>/fd/, provoni fillimisht të ekzekutoni një depo logjike të drejtpërdrejtë mbi prizën ekzistuese unix ose lidhjen 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

Faza 3: Rikuperimi i një vëllimi të fshirë Docker aktivizohet ext4 ose XFS pasi kontejneri u ndal¶

Po sikur të vrapoje docker compose down -v ose docker system prune --volumes, kështu që kontejneri është tashmë i ndalur dhe të gjitha /proc/<pid>/fd/ përshkruesit janë të mbyllur? Tani jeni në një garë kundër shkrimeve të diskut të sfondit në hostin Linux.

Hapi 1: Ngrini sistemin e skedarëve pritës Linux brenda 10 sekondave¶

1. Ndalo menjëherë Docker-in, Containerd-in, Kubelet-in dhe Cron-in në mënyrë që asnjë kontejner, kontroll shëndetësor ose rotator log të mos shkruajë një bajt tjetër në /var/lib/docker:

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

2. Kontrolloni se cila pajisje dhe skedarë bllok përmban /var/lib/docker:

   df -Th /var/lib/docker
   

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

3. Rimontoni ndarjen vetëm për lexim (ose transmetoni një imazh të papërpunuar të ndarjes mbi SSH në një makinë tjetër):
4. Nëse /var/lib/docker është në ndarjen e vet të dedikuar ose volumin LVM (për shembull /dev/nvme0n1p2 ose /dev/mapper/vg0-docker), rimontoni menjëherë vetëm për lexim:

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

5. Nëse /var/lib/docker është në rrënjë / ndarje (/), provoni të detyroni ndarjen rrënjë vetëm për lexim duke përdorur shkasin e kernelit Magic SysRq (echo u | sudo tee /proc/sysrq-trigger) ose sudo mount -o remount,ro /.
6. Nëse jeni në një VPS cloud (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Shkoni menjëherë në tastierën tuaj të internetit në cloud dhe klikoni Krijo fotografi në vëllimin e bllokut të serverit (ose transmetoni pajisjen e bllokut të papërpunuar mbi SSH në një server të dytë: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Hapi 2: Kontrolloni nëse të dhënat tuaja janë ende të vendosura në NJË TJETËR vëllim të pakrasitur ose overlay2 shtresë¶

Përpara se të gdhendni blloqe disqesh të pashpërndara, verifikoni që baza e të dhënave juaj nuk ishte ruajtur në të vërtetë në një montim bind ose në një vëllim të quajtur ndryshe që mbijetoi:

# 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

Hapi 3: Rikuperimi i drejtorive të volumit të shkëputur të Docker aktivizohet ext4 duke përdorur ext4 ditar (ext4magic dhe debugfs)¶

Kur docker volume rm fshin /var/lib/docker/volumes/<vol_name>/_data në një ext4 sistemi i skedarëve, ext4 zeron treguesit e drejtpërdrejtë të bllokut (i_block / rrënja e pemës së shtrirjes) në tabelën e inodes së gjallë. Megjithatë, ext4 ditar (inode <8>, në mënyrë tipike 128 MB te 1024 MB tampon unaza rrethore) ende mban kopje historike të tabelave ekzakte inode dhe blloqeve të direktoriumeve që nga përpara docker compose down -v u ekzekutua.

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

Vraponi ext4magic kundër ndarjes tuaj vetëm për lexim (ose .img kopjimi i fotografisë në një server të dytë), duke specifikuar një vulë kohore (-a) nga 5 minuta më parë që vrapove docker compose down -v ose 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

Hapi 4: Gdhendja e skedarëve të papërpunuar SQLite, PostgreSQL ose MySQL InnoDB kur ditari të jetë mbështjellë (XFS ose ext4)¶

Nëse hosti përdor XFS ose nëse ext4 ditari i mbështjellë tashmë mbi treguesit inode, përdorni nënshkrimin dhe gdhendjen e strukturës kundër imazhit të diskut të papërpunuar (docker_host_raw.img):

1. Për bazat e të dhënave SQLite3 (.sqlite, .db - p.sh., Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Çdo bazë të dhënash SQLite3 fillon me një kokë të pagabueshme ASCII 16-byte në bajt 0 të faqes së saj të parë prej 4 kilobyte: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), dhe ruan madhësinë e saktë të faqes së bazës së të dhënave (Bytes 16..17, në mënyrë tipike 4096) dhe madhësia totale e bazës së të dhënave në faqe (Bytes 28..31, numër i plotë 32-bit i madh endian) pikërisht brenda të njëjtit kokë.
2. Vraponi PhotoRec me [File Opt] -> [x] sqlite aktivizuar, ose skanoni ndarjen drejtpërdrejt me grep -ab "SQLite format 3" për të gjetur kompensimin e saktë të bajtit të skedarit tuaj SQLite të fshirë dhe ekstraktoni atë me të dd:

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

   Pasi të nxirret, drejtojeni sqlite3 carved.db ".recover" | sqlite3 repaired.db për të rindërtuar çdo faqe të paprekur të gjetheve të pemës B.

1. Për MySQL / MariaDB InnoDB (.ibd skedarët e tabelës): Çdo InnoDB .ibd tabela përbëhet nga sekuenciale 16 KB (16,384 byte) faqet që përmbajnë FIL_PAGE_INDEX (0x45BF) kreu dhe tabela janë unike space_id. Përdorni Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) paketa e veglave për të skanuar /dev/nvme0n1p1 për të gjithë 16 KB Indeksoni faqet e InnoDB dhe hidhni çdo rresht direkt në skedarët TSV/SQL për riimportim.
2. Për skedarët PostgreSQL Heap ($PGDATA/base/<db_oid>/<relfilenode>): PostgreSQL ruan çdo tabelë si të ngjitur 8 KB (8,192 byte) faqet e grumbullit që përmbajnë PageHeaderData (pd_lower, pd_upper, pd_special). Përdor pg_filedump ose pglazarus / pdu për të skanuar rajone të pacaktuara të diskut 8 KB faqet që përputhen me paraqitjen e kolonës së tabelës suaj (HeapTupleHeaderData) dhe rindërtoni rreshtat.

Faza 4: Kubernetes PVC, PV dhe etcd Rimëkëmbja e urgjencës së çastit¶

Në Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), duke fshirë aksidentalisht një Pretendim PersistentVolume (kubectl delete pvc), një StatefulSet, ose një hapësirë e tërë emrash (kubectl delete ns prod) ndjek një arkitekturë shumë të ndryshme nga Docker i pavarur.

Skenari A: PVC tregon Terminating (The Finalizer Lifesaver)¶

Vraponi:

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

Skenari B: PVC u fshi dhe kubectl get pv tregon Vëllimin e Përhershëm në Released shteti (ReclaimPolicy: Retain)¶

Vraponi:

kubectl get pv

Si të bëni një Released PV Available përsëri në 10 sekonda me humbje zero të të dhënave: 1. Ndryshoni objektin PersistentVolume dhe fshini spec.claimRef bllokoj:

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

Skenari C: Rivendosja e gjendjes së grupit të fshirë Kubernetes nga një etcd foto e çastit (etcdctl snapshot restore)¶

Po sikur dikush të vraponte kubectl delete namespace prod ose helm uninstall dhe fshiu 200 manifeste Kubernetes, Sekrete, ConfigMaps dhe përkufizime PV në një të vetë-menaxhuar kubeadm, k3s, ose RKE2 aeroplani i kontrollit?

1. ** Gjeni më të fundit etcd fotografi** (si parazgjedhje në /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, ose të planifikuar /var/backups/etcd/snapshot.db).
2. Verifiko integritetin e fotografisë përpara se të prekësh grupin e drejtpërdrejtë:

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

3. ** Ndalo kube-apiserver dhe etcd në nyjet e planit të kontrollit**:
4. në kubeadm (pods statike): Lëviz /etc/kubernetes/manifests/kube-apiserver.yaml dhe /etc/kubernetes/manifests/etcd.yaml përkohësisht për të /root/manifests_hold/ pra kubelet i ndalon pastër të dy kontejnerët, më pas i rezervon /var/lib/etcd te /var/lib/etcd.bak.
5. në k3s: Vraponi sudo systemctl stop k3s dhe sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. Rivendos etcd drejtoria e të dhënave aktivizohet 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. Lëvizni etcd.yaml dhe kube-apiserver.yaml përsëri në /etc/kubernetes/manifests/. Brenda 30 sekondave, kube-apiserver rilidhet me të restauruar etcd ruajeni dhe çdo objekt i fshirë Hapësirë emrash, Secret, ConfigMap dhe PersistentVolume rishfaqet.

Faza 5: Forcimi i vëllimeve Docker dhe Kubernetes kundër fshirjes aksidentale¶

Pasi të restaurohet databaza juaj e prodhimit, zbatoni këto katër parmakë arkitekturore në mënyrë që një gabim i vetëm CLI të mos mund të fshijë më kurrë një vëllim të drejtpërdrejtë:

• Ndrysho çdo prodhim Kubernetes StorageClass nga reclaimPolicy: Delete te reclaimPolicy: Retain: Si parazgjedhje, klasat e integruara të ruajtjes së cloud (gp2, gp3, standard-rwo) të paracaktuar në reclaimPolicy: Delete, që do të thotë fshirja e një PVC shkatërron diskun e cloud. Krijo një StorageClass me reclaimPolicy: Retain (ose rregulloni PV-të ekzistuese me kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') kështu që fshirja e një PVC ose Hapësirë emrash nuk e fshin kurrë vëllimin e bllokut themelor.
• Aktivizo AWS EBS Recycle Bin / GCP Snapshot Schedules / Velero me CSI Snapshots: Aktivizimi i koshit të riciklimit AWS EBS ruan çdo volum të fshirë EBS për 7 deri në 30 ditë edhe nëse shoferi CSI telefonon DeleteVolume.
• Mos përdorni kurrë docker system prune --volumes në skriptet e automatizuara të pastrimit ose ekzekutuesit CI/CD: Nëse një kontejner i bazës së të dhënave të prodhimit prishet shkurtimisht (Exited (1)) në momentin e saktë që funksionon një cron job docker system prune -a --volumes -f, Docker i konsideron vëllimet e tij anonime "të papërdorura" dhe i fshin ato përgjithmonë. Rrish --volumes nga të gjitha skriptet e pastrimit.
• Përdor montime të qarta të lidhjes së hostit (/srv/prod_data/postgres:/var/lib/postgresql/data) ose bazat e të dhënave të menaxhuara nga jashtë për ngarkesat e prodhimit të gjendjes: Ndryshe /var/lib/docker/volumes/, pret direktoriumet bind-mount jashtë /var/lib/docker/ nuk janë prekur kurrë nga docker compose down -v, docker volume rm, ose docker system prune --volumes.

Numrat rajonalë të urgjencës dhe protokollet e agjencive¶

Kur fshirja e një kontejneri ose ruajtja Kubernetes ndikon në operacionet klinike të spitalit, dërgimin e sigurisë publike ose të dhënat personale të rregulluara, përshkallëzoni menjëherë:

• Shtetet e Bashkuara dhe Kanadaja: Telefono 911 nëse një dështim i grupit të kontejnerëve çaktivizon monitorimin klinik të pacientit, sistemet EHR ose dërgimin e urgjencës. Raportoni fshirjen e infrastrukturës së kontejnerëve me qëllim të keq ose incidente kibernetike te CISA (1-844-Say-CISA / cisa.gov/report) ose Qendra Kanadeze për Sigurinë Kibernetike (1-833-CYBER-88).
• Mbretëria e Bashkuar: Telefono 999 për kërcënimet ndaj jetës ose infrastrukturës kritike të NHS. Sipas GDPR në Mbretërinë e Bashkuar, shkatërrimi i përhershëm ose humbja e disponueshmërisë së të dhënave personale pa një kopje rezervë të rikuperueshme kërkon vlerësimin e një njoftimi 72-orësh për shkelje në ICO (0303 123 1113).
• Bashkimi Evropian: Telefono 112 në të gjitha shtetet anëtare të BE-së. Subjektet sipas Direktivës NIS2 duhet të paraqesin një paralajmërim të hershëm në CSIRT-in e tyre kombëtar brenda 24 orëve pas një ndërprerjeje të rëndë të shërbimit dhe humbja e përhershme e të dhënave personale shkakton raportimin **Neni 33 ** GDPR brenda 72 orëve.
• Australi dhe Zelanda e Re: Telefono 000 në Australi ose 111 në Zelandën e Re; raportoni incidentet kritike të infrastrukturës në ACSC (1300 CYBER1).
• **India dhe Azi-Paqësori **: Telefono 112 në Indi për përgjigje emergjente; raportoni incidentet e sigurisë së resë kompjuterike ose të kontejnerëve te CERT-In (incident@cert-in.org.in) brenda afatit të detyrueshëm 6-orësh.

Pyetjet e bëra shpesh¶

A docker compose down -v fshij montimet e lidhjes së hostit (./data:/var/lib/mysql) apo vetëm vëllimet Named dhe Anonim Docker?¶

`docker compose down -v` VETËM fshin vëllimet e emërtuara të deklaruara në `volumes:` seksioni i `docker-compose.yml` dhe vëllime anonime të bashkangjitura në kontejnerë; atë kurrë fshin skedarët brenda një montimi të lidhjes së hostit (si p.sh `- /opt/mysql_data:/var/lib/mysql` ose `- ./postgres_data:/var/lib/postgresql/data`). Nëse skedari juaj i kompozimit përdori një shteg pritës duke filluar me `/` ose `./`, kontrolloni atë dosje në host tani: skedarët tuaj janë ende 100 për qind të paprekur.

Pse bëri docker system prune --volumes Të fshihet vëllimi i bazës së të dhënave kur kam ndalur kontejnerin vetëm për 2 minuta për të përditësuar një variabël mjedisi?¶

Prisni me kujdes për dallimin ndërmjet `docker stop` dhe `docker rm`: nëse një enë është thjesht `Stopped / Exited` (të dukshme në `docker ps -a`), `docker system prune --volumes` bën jo fshini vëllimet e tij sepse kontejneri i ndalur ende i referon ato. Megjithatë, nëse vrapove `docker rm ` (për të rikrijuar kontejnerin me flamuj të rinj) ose nëse keni kaluar `docker system prune -a --volumes` (i cili fillimisht fshin të gjithë kontejnerët e ndaluar dhe pastaj fshin të gjitha vëllimet që nuk janë më të lidhura me ndonjë enë), vëllimi u bë "i varur" në milisekondën që ena e ndalur u hoq dhe u fshi menjëherë pas kësaj.

A mund të rikuperoj një vëllim të fshirë Docker brenda Docker Desktop në një Mac (Apple Silicon / Intel) ose Windows (WSL2)?¶

Po, nëse dilni menjëherë nga Docker Desktop në mënyrë që makina virtuale të ndalojë së punuari `fstrim` kundër diskut virtual. Në macOS, Docker ruan të gjitha vëllimet e Linux brenda `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; në Windows WSL2, brenda `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Kopjojeni atë `.raw` ose `.vhdx` skedari menjëherë në një SSD të jashtëm, bashkëngjitni atë vetëm për lexim në Linux (duke përdorur `losetup -Pr` për `.raw` ose `qemu-nbd -r` për `.vhdx`), dhe vraponi `ext4magic` ose `PhotoRec` kundër virtuales `ext4` ndarje brenda.

Po sikur të fshija një Kubernetes StatefulSet me kubectl delete statefulset postgres? A i fshiu kjo edhe PVC-të e mia?¶

Nr. Si parazgjedhje në Kubernetes (përveç nëse `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` ishte konfiguruar në mënyrë eksplicite në Kubernetes 1.27+), duke funksionuar `kubectl delete statefulset` fshin kontrolluesin StatefulSet dhe Pods-in e tij, duke i lënë të gjitha `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) dhe të dhënat e tyre themelore 100 për qind të paprekura. Thjesht ri-aplikoni tuajin `StatefulSet` Manifesti YAML me të njëjtin emër dhe `volumeClaimTemplates`, dhe Pods-et e reja automatikisht do të ribashkohen me ekzistuesin `data-postgres-0` PVC.

Si mund të aksesoj skedarët brenda një Docker overlay2 drejtoria kur kontejneri refuzon të fillojë (CrashLoopBackOff / Exited (1))?¶

Mos e fshini kontejnerin e rrëzuar. Për sa kohë që kontejneri i ndalur ekziston ende në `docker ps -a`, shtresa e saj e shkruajtshme dhe montimet e volumit janë plotësisht të paprekura në disk. Ju ose mund të kopjoni skedarë drejtpërdrejt nga kontejneri i ndaluar duke përdorur `docker cp :/var/lib/postgresql/data /root/rescued_data`, ose gjeni hostin e tij të saktë `overlay2` rrugë duke vrapuar `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` dhe leximi i direktoriumit si `root`.

Po sikur dikush të fshinte një Kubernetes Namespace (kubectl delete ns prod) dhe të gjitha PVC-të kishin reclaimPolicy: Delete në AWS EBS ose GCP?¶

Nëse drejtuesi CSI i cloud (`ebs.csi.aws.com` ose `pd.csi.storage.gke.io`) është ekzekutuar tashmë `DeleteVolume` sepse `reclaimPolicy` ishte `Delete`, kontrolloni menjëherë tre rrjetat e sigurisë në nivelin e resë kompjuterike: (1) kontrolloni **AWS Recycle Bin për vëllimet EBS** në konsolën AWS EC2 (nëse një rregull mbajtjeje ishte aktiv në llogari/etiketa, vëllimi i fshirë EBS qëndron në koshin e riciklimit dhe mund të rikthehet me 1 klik); (2) kontrolloni ** AWS Backup / DLM / GCP Snapshot Schedules** për fotografinë më të fundit të automatizuar të volumit; dhe (3) kontrolloni nëse baza juaj e të dhënave po transmetonte WAL/binlog (`WAL-G`, `pgBackRest`, `Litestream`) në një kovë S3/GCS.

Udhëzues të lidhur¶

• Disku i serverit 100% i mbushur (0 bajt falas): bloating e bazës së të dhënave WAL, pemë B e korruptuar dhe rikuperim i hapësirës zero
• "rm -rf" aksidentale ose "Shift+Delete" në Linux, macOS ose Windows: rimontim i menjëhershëm vetëm për lexim dhe gdhendje inode
• Korrupsioni i zinxhirit të fotografive të çastit të makinës virtuale VMDK, VHDX dhe qcow2 dhe shpëtimi i hipervizorit
• Kryerja aksidentale Git e çelësave AWS, skedarit .env ose çelësit privat SSH në repon publike GitHub
• Kriza e mbajtjes së uebit, migrimi dhe restaurimi i rezervave
• Rezervimet e kompjuterit, strategjia 3-2-1 dhe rikuperimi nga fatkeqësitë
• Numrat e urgjencës sipas vendit

Burimet dhe udhëzimet zyrtare¶

• Dokumentacioni zyrtar i Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Mbrojtja e objektit të ruajtjes në përdorim (kubernetes.io/pvc-protection Finalizuesit), Rikthimi i Vëllimeve të Përhershme (Retain vs. Delete), dhe operativ etcd Grupe për Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Menaxho të dhënat në Docker: Volume, Bind Mounts, overlay2 Arkitektura e Driver Storage, dhe Prune Reference.
• Organizata e kernelit Linux (kernel.org): The /proc Sistemi i skedarëve (procfs Hapni Rimëkëmbjen e përshkruesit të skedarit nëpërmjet /proc/<pid>/fd/) dhe Specifikimi i ditarit Ext4.
• ext4magic Dokumentacioni i Projektit (ext4magic.sourceforge.net): Rikuperimi i Transaksioneve Inode dhe Ditari Forensic në sistemet e skedarëve Ext3/Ext4.
• Instituti Kombëtar i Standardeve dhe Teknologjisë (NIST) (Shtetet e Bashkuara): Publikimi special 800-190: Udhëzuesi i sigurisë së kontejnerëve të aplikacionit dhe rikuperimi i incidentit.