Kiwango cha Uzalishaji wa Docker au Kubernetes Imefutwa: Kuokoa docker system prune --volumes, overlay2 Inodes, na etcd Vijipicha¶

Kukimbia docker compose down -v, docker system prune -a --volumes, docker volume rm, au kubectl delete pvc kwenye kichupo kibaya cha terminal katika uzalishaji ni mojawapo ya njia za haraka zaidi za kufuta PostgreSQL moja kwa moja, MySQL, MariaDB, Redis, MongoDB, au ujazo wa hifadhidata wa SQLite. Tofauti na vijisehemu vya mashine ya wingu vinavyohamia kwenye pipa la kusaga tena la siku 7, kiendesha kiasi cha ndani cha Docker (/var/lib/docker/volumes/<name>/_data) na Kubernetes local-path / hostPath watoa huduma wanatoa mara moja POSIX ya kawaida unlink() na rmdir() hupiga simu moja kwa moja dhidi ya mfumo wa faili wa mwenyeji wa Linux (ext4, XFS, au Btrfs) Kila maandishi yanayotokea kwenye seva pangishi ya Linux baada ya amri kukamilika inaweza kubatilisha vizuizi vya hifadhidata vilivyotolewa kwenye diski. Ikiwa diski yako ya seva imejaa hadi asilimia 100 (0 bytes free) kabla ya mtu kukimbia docker system prune --volumes kwa hofu, shauriana seva diski 100% imejaa, hifadhidata ya WAL logi bloat, na uokoaji wa nafasi sifuri; kwa kufutwa kwa faili za Linux nje ya vyombo, ona ajali rm -rf au Shift-Delete kwenye ext4, XFS, APFS, na NTFS: weka upya tu kusoma na kuchonga ingizo na mashine virtual VMDK, VHDX, na qcow2 snapshot mnyororo rushwa na uokoaji hypervisor. Ikiwa hitilafu hii ya uzalishaji itaathiri utunzaji wa wagonjwa hospitalini, upelekaji wa dharura, au mifumo ya usalama ya huduma za umma, piga simu kwa nambari yako ya dharura ya eneo lako (911 nchini Marekani na Kanada, 112 katika Umoja wa Ulaya, 999 nchini Uingereza) au angalia saraka yetu ya nambari za dharura.

Fanya hivi sasa¶

1. USIKIMBIE docker compose up -d, systemctl restart docker, au tuma tena ganda la Kubernetes: Kuunda tena kontena au kuwasha tena daemon ya Docker huandika megabaiti mpya overlay2 metadata, kumbukumbu za kontena za JSON, na faili za hifadhidata zilizoanzishwa upya (initdb) moja kwa moja juu ya halisi ext4 au XFS huzuia sauti yako iliyofutwa ikikaa sekunde chache zilizopita.
2. Angalia baada ya sekunde 5 ikiwa mchakato wa kontena (postgres, mysqld, redis-server, node, python) bado inaendelea kwenye kumbukumbu (ps aux na sudo lsof +L1): Iwapo mtu alifuta faili ndani ya sauti iliyopachikwa au kutenganisha sauti isiyojulikana wakati chombo kinaendelea kufanya kazi, kinu cha Linux huhifadhi asilimia 100 ya faili za hifadhidata ambazo hazijaunganishwa zikiwa hai kwenye diski mradi tu Kitambulisho cha Mchakato wa mpangishi wa chombo.PID) inashikilia maelezo ya faili wazi (FD) Unaweza kunakili faili hizo moja kwa moja kutoka /proc/<PID>/fd/ au /proc/<PID>/root/ bila kupoteza data kabla ya kontena kusimama.
3. ** Ikiwa chombo tayari kimesimamishwa na kiasi kilifutwa (docker compose down -v au docker system prune --volumes), fungia diski ya mwenyeji inaandika mara moja**: Acha daemon ya Docker (sudo systemctl stop docker.socket docker.service containerd) kwa hivyo vyombo vya mandharinyuma na ukaguzi wa afya huacha kuandika kumbukumbu /var/lib/docker, basi ama weka tena /var/lib/docker (au mzizi / kizigeu) kusoma tu (sudo mount -o remount,ro /) au piga picha ya haraka ya kiwango cha wingu (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) kabla ya kugusa chochote.
4. Ikiwa uko kwenye Kubernetes (kubectl delete pvc au kubectl delete namespace), angalia PersistentVolume (PV) ReclaimPolicy (kubectl get pv) mara moja:
5. Ikiwa PV alikuwa persistentVolumeReclaimPolicy: Retain, data yako haijafutwa: the PV tu kuhamia Released hali na diski yako ya wingu (EBS, Azure Disk, Ceph RBD, NFS) iko sawa kwa asilimia 100.
6. Hata kama kubectl delete pvc amekwama Terminating, Kubernetes Wakamilishaji (kubernetes.io/pvc-protection) zuia kiendesha CSI kufuta hifadhi ya msingi mradi tu Pod yoyote irejelee PVC. Usifute Pod hadi unakili data kutoka kwa Pod inayoendesha.
7. Picha kizigeu cha msingi cha kizuizi (dd / ddrescue juu ya SSH) kwa diski ya nje au kiasi tofauti cha wingu kabla ya kukimbia ext4magic, extundelete, au PhotoRec: Kamwe usiendeshe vichonga faili vinavyoandika faili za towe kwenye kizigeu sawa cha diski ambako unarejesha /var/lib/docker/volumes.
8. Kwa hali ya nguzo ya Kubernetes iliyoharibika au iliyofutwa kwa bahati mbaya (kubectl delete crd / namespace), acha kube-apiserver na kurejesha yako ya hivi karibuni etcd picha (etcdctl snapshot restore): Ikiwa nguzo iko etcd ilifutwa wakati kiasi cha msingi cha hifadhi ya wingu bado kipo, inarejeshwa etcd huponya yote PV, PVC, Secret, na ConfigMap vitu kwa wakati mmoja.

Mti wa uamuzi: kiasi cha Docker kilichofutwa, overlay2 layer, au Kubernetes PVC triage¶

Tumia chati hii ya mtiririko kuchagua njia ya urejeshaji ya haraka zaidi ya sifuri-hasara kulingana na kama mchakato wa kontena ungali hai, iwe sauti iliungwa mkono na diski ya ndani au hifadhi ya CSI ya wingu, na mfumo wa faili unaopangisha. /var/lib/docker:

flowchart TD
    Start["Data ya Uzalishaji Haipo Baada ya Docker au Kubernetes Futa Amri"] --> WhichEnv{"Ni Jukwaa & Amri gani Ilisababisha Hasara?"}

    WhichEnv -->|"Docker: Chombo Bado Kinaendelea (Faili Zisizounganishwa Ndani ya Kiasi/Kontena)"| ProcRescue["Okoa Vielelezo vya Faili Visivyounganishwa kupitia sudo lsof +L1 na /proc/PID/fd/N au /proc/PID/root/"]

    WhichEnv -->|"Docker: Chombo Kimesimamishwa & Kiasi Kimefutwa (tunga chini -v / prune --volumes)"| StopDocker["Endesha Mara Moja: sudo systemctl stop docker.socket docker imebeba"]

    WhichEnv -->|"Kubernetes: kubectl kufuta pvc / pv / statefulset / namespace"| K8sCheck{"Pod Bado Inaendesha AU PVC Imekwama Katika Kusitisha?"}

    K8sCheck -->|"Ndiyo: Pod Bado Inaendelea (Finalizer Inazuia CSI Futa)"| K8sExec["USIFUTE Pod -> Endesha kubectl exec / pg_dump / tar juu ya stdout kwa Diski ya Ndani Mara moja"]
    K8sCheck -->|"Hapana: Pod Gone -> Angalia kubectl kupata pv"| ReclaimCheck{"Sera ya Kurudisha PV Ilikuwa Nini?"}

    ReclaimCheck -->|"Hifadhi (Hali ya PV = Imetolewa)"| ClearClaimRef["100% Data Imbayo -> Hariri PV ili Kuondoa spec.claimRef.uid -> Funga tena kwa PVC Mpya"]
    ReclaimCheck -->|"Futa (Cloud EBS / PD / Longhorn / Njia ya Ndani)"| CloudOrLocal{"Kiasi cha Wingu CSI au Diski ya Mwenyeji wa Ndani?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Angalia Bin ya Usafishaji ya Dashibodi ya Wingu / Vijipicha vya EBS vya Kiotomatiki / Tupio la Ceph RBD (rbd takataka ls)"]
    CloudOrLocal -->|"Diski ya Nodi ya Ndani (njia ya ndani / Njia ya mwenyeji)"| StopDocker

    StopDocker --> RemountRO["Remount Host Partition Soma-Pekee (mount -o remount,ro) AU Tiririsha Picha ya Zuia kupitia SSH"]
    RemountRO --> HostFS{"Ni Majeshi gani ya Mfumo wa faili /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Tumia debugfs / ext4magic Journal Inode Transaction Rollback (-muhuri wa muda)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Tumia Btrfs Roots / xfs_irecover / Uchongaji Sahihi Maalum kwa SQLite, Postgres Heap, au InnoDB .ibd"]

Awamu ya 1: Jinsi Docker na Kubernetes hufuta kiasi kwenye diski¶

Kabla ya kutekeleza amri yoyote ya uokoaji, elewa mahali data yako iliishi kwenye seva pangishi ya Linux na amri ya kufuta iligusa nini hasa:

Awamu ya 2: Kuokoa faili za hifadhidata wazi kutoka kwa chombo ambacho bado kinafanya kazi (/proc/<pid>/fd/)¶

Subiri: je chombo bado kinaendelea kufanya kazi sasa hivi? Mara kwa mara, mhandisi huendesha hati ya uhamishaji wa programu, kazi ya kusafisha cron, au mwongozo rm -rf /var/lib/postgresql/data/* au rm /app/data/production.sqlite3 ndani ya chombo kinachoendesha, au kufuta folda ya msingi ya bind-mount /opt/app/data wakati chombo chenyewe (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) ni bado inaendelea na inaendelea.

Katika Linux, faili haifutwa kutoka kwa diski wakati rm au unlink() inaitwa. Vizuizi vyake vya diski na ingizo hubaki Asilimia 100 imetengwa na kusomeka hadi mchakato wa mwisho ukishikilia maelezo ya faili wazi (FD) kwa ingizo hilo huifunga au kutoka.

Hatua ya 1: Tafuta kitambulisho cha Mchakato wa mwenyeji (PID) ya mchakato wa kontena¶

Kwenye nodi ya mwenyeji wa Linux (sio ndani ya kontena), pata mwenyeji PID ya hifadhidata yako au mchakato wa maombi:

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)

Hatua ya 2: Nakili faili za hifadhidata ambazo hazijaunganishwa moja kwa moja /proc/<PID>/fd/¶

usisitishe au uwashe tena chombo. Wakati mchakato bado unaendelea, nakili maelezo ya faili mbichi moja kwa moja kwenye folda salama kwenye mwenyeji wako:

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

Hatua ya 3: Bora zaidi: Tekeleza utupaji wa moja kwa moja wa kimantiki (pg_dump / mysqldump / .backup) kabla ya kontena kufunga FDs¶

Kama postgres au mysqld bado inaendelea na faili zake za data zimefunguliwa kwenye kumbukumbu na /proc/<PID>/fd/, jaribu kuendesha utupaji wa moja kwa moja wa kimantiki juu ya tundu la unix lililopo au muunganisho wa TCP kwanza:

# 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

Awamu ya 3: Kurejesha kiasi cha Docker kilichofutwa ext4 au XFS baada ya kontena kusimama¶

Nini kama wewe mbio docker compose down -v au docker system prune --volumes, kwa hivyo kontena tayari imesimamishwa na yote /proc/<pid>/fd/ maelezo yamefungwa? Sasa uko kwenye mbio dhidi ya diski ya usuli huandika kwenye mwenyeji wa Linux.

Hatua ya 1: Fanya mfumo wa faili wa mwenyeji wa Linux ndani ya sekunde 10¶

1. Simamisha Doka, iliyo na kontena, kubelet, na cron mara moja kwa hivyo hakuna kontena, ukaguzi wa afya, au kizungusha logi kinachoandika baiti nyingine kwa /var/lib/docker:

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

2. Angalia ni kifaa gani cha kuzuia na mfumo wa faili unashikilia /var/lib/docker:

   df -Th /var/lib/docker
   

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

3. Weka upya kizigeu cha Kusoma Pekee (au tiririsha taswira ya kizigeu mbichi juu ya SSH hadi kwa mashine nyingine):
4. Kama /var/lib/docker iko kwenye kizigeu chake kilichojitolea au kiasi cha LVM (kwa mfano /dev/nvme0n1p2 au /dev/mapper/vg0-docker), weka tena usomaji pekee mara moja:

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

5. Kama /var/lib/docker iko kwenye mizizi / kizigeu (/), jaribu kulazimisha kizigeu cha mizizi kusoma tu kwa kutumia kichocheo cha Uchawi cha kernel SysRq (echo u | sudo tee /proc/sysrq-trigger) au sudo mount -o remount,ro /.
6. Ikiwa uko kwenye VPS ya wingu (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Nenda mara moja kwenye kiweko chako cha wavuti na ubofye Unda Picha kwenye sauti ya kuzuia ya seva (au tiririsha kifaa kibichi cha kuzuia juu ya SSH hadi seva ya pili: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz")

Hatua ya 2: Angalia ikiwa data yako bado iko katika sauti NYINGINE ambayo haijakatwa au overlay2 safu¶

Kabla ya kuchonga vizuizi vya diski ambavyo havijatengwa, thibitisha kwamba hifadhidata yako haikuhifadhiwa kwenye kipachiko au ujazo uliopewa jina tofauti ambao ulisalia:

# 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

Hatua ya 3: Kurejesha saraka za kiasi cha Docker ambazo hazijaunganishwa zimewashwa ext4 kwa kutumia ext4 Jarida (ext4magic na debugfs)¶

Wakati docker volume rm hufuta /var/lib/docker/volumes/<vol_name>/_data kwenye ext4 mfumo wa faili, ext4 sifuri nje ya viashiria vya kuzuia moja kwa moja (i_block / kadiri mzizi wa mti) kwenye jedwali la ingizo hai. Hata hivyo, ext4 jarida (inode <8>, kwa kawaida 128 MB kwa 1024 MB bafa ya pete ya duara) bado ina nakala za kihistoria za jedwali halisi za ingizo na vizuizi vya saraka kutoka hapo awali docker compose down -v ilitekelezwa.

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

Kimbia ext4magic dhidi ya kizigeu chako cha kusoma pekee (au .img nakala ya picha kwenye seva ya pili), ikibainisha muhuri wa muda (-a) kutoka dakika 5 kabla ulikimbia docker compose down -v au 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

Hatua ya 4: Kuchonga faili mbichi za SQLite, PostgreSQL, au MySQL InnoDB wakati jarida limefungwa (XFS au ext4)¶

Ikiwa mwenyeji anatumia XFS au ikiwa ext4 jarida ambalo tayari limefungwa juu ya viashiria vya ingizo, tumia saini na muundo wa kuchonga dhidi ya picha ya diski mbichi (docker_host_raw.img):

1. Kwa Hifadhidata za SQLite3 (.sqlite, .db - k.m., Vaultwarden, Nextcloud, Mratibu wa Nyumbani, Gitea, Grafana): Kila hifadhidata ya SQLite3 huanza na kichwa cha ASCII cha baiti 16 katika byte 0 ya ukurasa wake wa kwanza wa kilobaiti 4: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), na huhifadhi saizi halisi ya ukurasa wa hifadhidata (Bytes 16..17, kwa kawaida 4096) na jumla ya saizi ya hifadhidata katika kurasa (Bytes 28..31, big-endian 32-bit integer) ndani kabisa ya kichwa hicho hicho.
2. Kimbia PhotoRec na [File Opt] -> [x] sqlite kuwezeshwa, au changanua kizigeu moja kwa moja na grep -ab "SQLite format 3" kupata urekebishaji kamili wa faili yako ya SQLite iliyofutwa na uitoe nayo dd:

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

   Mara baada ya kuondolewa, kukimbia sqlite3 carved.db ".recover" | sqlite3 repaired.db kuunda upya kila ukurasa wa jani la mti wa B.

1. ** Kwa MySQL / MariaDB InnoDB (.ibd faili za meza)**: Kila InnoDB .ibd jedwali lina mfuatano 16 KB (16,384 byte) kurasa zenye FIL_PAGE_INDEX (0x45BF) kichwa na ya kipekee ya jedwali space_id. Tumia Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) zana ya kuchanganua /dev/nvme0n1p1 kwa wote 16 KB Kurasa za faharasa za InnoDB na utupe kila safu mlalo moja kwa moja kwenye faili za TSV/SQL ili kuagiza tena.
2. Kwa Faili za Lundo za PostgreSQL ($PGDATA/base/<db_oid>/<relfilenode>): PostgreSQL huhifadhi kila jedwali kama dhabiti 8 KB (8,192 byte) lundo la kurasa zenye PageHeaderData (pd_lower, pd_upper, pd_special) Tumia pg_filedump au pglazarus / pdu kuchanganua sehemu za diski ambazo hazijatengwa 8 KB kurasa zinazolingana na mpangilio wa safu wima ya jedwali lako (HeapTupleHeaderData) na uunda upya safu.

Awamu ya 4: Kubernetes PVC, PV, na etcd Picha ya Urejeshaji wa Dharura¶

Katika Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), kufuta kwa bahati mbaya PersistentVolumeClaim (kubectl delete pvc), StatefulSet, au Nafasi nzima ya Majina (kubectl delete ns prod) hufuata usanifu tofauti sana kuliko Docker iliyosimama.

Mfano A: Maonyesho ya PVC Terminating (The Finalizer Lifesaver)¶

Endesha:

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

Mfano B: PVC ilifutwa, na kubectl get pv inaonyesha PersistentVolume in Released jimbo (ReclaimPolicy: Retain)¶

Endesha:

kubectl get pv

Jinsi ya kutengeneza a Released PV Available tena katika sekunde 10 na kupoteza data sifuri: 1. Hariri PersistentVolume kitu na kufuta spec.claimRef kizuizi:

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

Mfano C: Kurejesha hali ya nguzo ya Kubernetes iliyofutwa kutoka kwa etcd picha (etcdctl snapshot restore)¶

Nini ikiwa mtu alikimbia kubectl delete namespace prod au helm uninstall na kufuta maelezo 200 ya Kubernetes, Siri, ConfigMaps na ufafanuzi wa PV kwenye programu inayojidhibiti. kubeadm, k3s, au RKE2 ndege ya kudhibiti?

1. Tafuta yako ya hivi punde etcd snapshot (kwa chaguo-msingi in /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, au ulioratibiwa /var/backups/etcd/snapshot.db)
2. Thibitisha uadilifu wa muhtasari kabla ya kugusa nguzo ya moja kwa moja:

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

3. Acha kube-apiserver na etcd kwenye nodi ya ndege ya kudhibiti:
4. Kwenye kubeadm (maganda tuli): Sogeza /etc/kubernetes/manifests/kube-apiserver.yaml na /etc/kubernetes/manifests/etcd.yaml kwa muda kwa /root/manifests_hold/ hivyo kubelet husimamisha vyombo vyote viwili kwa usafi, kisha kuweka nakala rudufu /var/lib/etcd kwa /var/lib/etcd.bak.
5. Kwenye k3s: kukimbia sudo systemctl stop k3s na sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. Rudisha etcd saraka ya data imewashwa 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. Sogeza etcd.yaml na kube-apiserver.yaml kurudi ndani /etc/kubernetes/manifests/. Ndani ya sekunde 30, kube-apiserver inaunganishwa tena na iliyorejeshwa etcd kuhifadhi na kila kitu kilichofutwa cha Namespace, Siri, ConfigMap, na PersistentVolume kinatokea tena.

Awamu ya 5: Ugumu wa viwango vya Docker na Kubernetes dhidi ya kufutwa kwa bahati mbaya¶

Mara tu hifadhidata yako ya uzalishaji inaporejeshwa, tekeleza kanuni hizi nne za usanifu ili chapa moja ya CLI isiweze kufuta tena sauti ya moja kwa moja:

• Badilisha kila toleo la Kubernetes StorageClass kutoka reclaimPolicy: Delete kwa reclaimPolicy: Retain: Kwa chaguo-msingi, Darasa za Hifadhi za wingu zilizojengwa (gp2, gp3, standard-rwo) chaguo-msingi kwa reclaimPolicy: Delete, ikimaanisha kufuta PVC huharibu diski ya wingu. Unda a StorageClass na reclaimPolicy: Retain (au bandika PV zilizopo na kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') kwa hivyo kufuta PVC au Namespace hakuwahi kufuta kiasi cha msingi cha kizuizi.
• Washa Ratiba za AWS EBS Recycle Bin / GCP Snapshot Ratiba / Velero yenye Snapshots za CSI: Kuwasha AWS EBS Recycle Bin huhifadhi sauti yoyote ya EBS iliyofutwa kwa siku 7 hadi 30 hata kama kiendeshi cha CSI kinapiga simu. DeleteVolume.
• Kamwe usitumie docker system prune --volumes katika hati za kusafisha kiotomatiki au viendeshaji vya CI/CD: Ikiwa kontena la hifadhidata ya uzalishaji litaanguka kwa muda mfupi (Exited (1)) kwa wakati halisi kazi ya cron inaendeshwa docker system prune -a --volumes -f, Docker inazingatia juzuu zake zisizojulikana "hazijatumika" na kuzifuta kabisa. Ukanda --volumes kutoka kwa hati zote za kusafisha.
• Tumia vipandikizi vya kuunganisha seva pangishi (/srv/prod_data/postgres:/var/lib/postgresql/data) au hifadhidata zinazodhibitiwa na nje za upakiaji wa hali ya juu wa uzalishaji: Tofauti /var/lib/docker/volumes/, pandishi saraka za bind-mount nje /var/lib/docker/ haijaguswa kamwe na docker compose down -v, docker volume rm, au docker system prune --volumes.

Nambari za dharura za kikanda na itifaki za wakala¶

Wakati kontena au ufutaji wa hifadhi ya Kubernetes unaathiri shughuli za kliniki za hospitali, utumaji wa usalama wa umma, au data ya kibinafsi iliyodhibitiwa, huongezeka mara moja:

• Marekani na Kanada: Piga 911 ikiwa hitilafu ya nguzo ya kontena itazima ufuatiliaji wa kimatibabu wa mgonjwa, mifumo ya EHR au utumaji wa dharura. Ripoti ufutaji wa miundombinu ya kontena au matukio ya mtandaoni kwa CISA (1-844-Say-CISA / cisa.gov/report) au Kituo cha Kanada cha Usalama wa Mtandao (1-833-CYBER-88).
• Uingereza: Piga 999 kwa vitisho kwa maisha au miundombinu muhimu ya NHS. Chini ya GDPR ya Uingereza, uharibifu wa kudumu au upotevu wa upatikanaji wa data ya kibinafsi bila hifadhi rudufu inayoweza kurejeshwa inahitaji kutathmini arifa ya ukiukaji wa saa 72 kwa ICO (0303 123 1113).
• Umoja wa Ulaya: Piga 112 katika nchi zote wanachama wa EU. Huluki chini ya Maelekezo ya NIS2 lazima ziwasilishe onyo la mapema kwa CSIRT yao ya kitaifa ndani ya saa 24 baada ya hitilafu kali ya huduma, na upotevu wa kudumu wa data ya kibinafsi husababisha Kifungu cha 33 cha GDPR kuripoti ndani ya saa 72.
• Australia na New Zealand: Piga 000 nchini Australia au 111 huko New Zealand; kuripoti matukio muhimu ya miundombinu kwa ACSC (1300 CYBER1).
• India na Asia-Pacific: Piga 112 nchini India kwa majibu ya dharura; ripoti matukio ya usalama wa wingu au kontena kwa CERT-In (incident@cert-in.org.in) ndani ya dirisha la lazima la saa 6.

Maswali yanayoulizwa mara kwa mara¶

Je. docker compose down -v futa vipandikizi vya kufunga mwenyeji (./data:/var/lib/mysql) au idadi ya Docker iliyotajwa tu na isiyojulikana?¶

`docker compose down -v` Ufutaji TU Kiasi kilichotajwa kilichotangazwa katika `volumes:` sehemu ya `docker-compose.yml` na juzuu zisizojulikana zilizoambatishwa kwenye makontena; hiyo kamwe hufuta faili ndani ya mfungaji wa mfungaji (kama vile `- /opt/mysql_data:/var/lib/mysql` au `- ./postgres_data:/var/lib/postgresql/data`) Ikiwa faili yako ya kutunga ilitumia njia ya mwenyeji kuanzia `/` au `./`, angalia folda hiyo kwenye seva pangishi sasa hivi: faili zako bado ziko sawa kwa asilimia 100.

Kwa nini docker system prune --volumes Futa kiasi cha hifadhidata yangu niliposimamisha kontena kwa dakika 2 tu kusasisha utofauti wa mazingira?¶

Subiri kwa uangalifu tofauti kati yao `docker stop` na `docker rm`: ikiwa chombo ni tu `Stopped / Exited` (inaonekana katika `docker ps -a`), `docker system prune --volumes` hufanya sivyo futa kiasi chake kwa sababu chombo kilichosimamishwa bado kinarejelea. Walakini, ikiwa ulikimbia `docker rm ` (kuunda tena kontena na bendera mpya) au ikiwa umepita `docker system prune -a --volumes` (ambayo kwanza hufuta vyombo vyote vilivyosimamishwa na basi hufuta juzuu zote ambazo hazijaambatishwa tena kwenye kontena lolote), sauti ikawa "inaning'inia" sekunde ambayo chombo kilichosimamishwa kiliondolewa na kufutwa mara baada ya hapo.

Ninaweza kupata kiasi cha Docker kilichofutwa ndani ya Dawati la Docker kwenye Mac (Apple Silicon / Intel) au Windows (WSL2)?¶

Ndio, ukiacha Kompyuta ya Docker mara moja ili mashine pepe ikome kufanya kazi `fstrim` dhidi ya diski halisi. Kwenye macOS, Docker huhifadhi viwango vyote vya Linux ndani `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; kwenye Windows WSL2, ndani `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Nakili hiyo `.raw` au `.vhdx` faili kwa SSD ya nje mara moja, ambatisha kusoma tu kwenye Linux (kwa kutumia `losetup -Pr` kwa `.raw` au `qemu-nbd -r` kwa `.vhdx`), na kukimbia `ext4magic` au `PhotoRec` dhidi ya mtandaoni `ext4` kizigeu ndani.

Nini ikiwa ningefuta Kubernetes StatefulSet na kubectl delete statefulset postgres? Hiyo ilifuta PVC zangu pia?¶

Hapana. Kwa chaguo-msingi katika Kubernetes (isipokuwa `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` ilisanidiwa kwa uwazi kwenye Kubernetes 1.27+), inayoendeshwa `kubectl delete statefulset` inafuta kidhibiti cha StatefulSet na Pods zake, kuacha yote `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) na data zao za msingi zikiwa shwari kwa asilimia 100. Tuma maombi yako tena `StatefulSet` faili ya maelezo ya YAML yenye jina sawa na `volumeClaimTemplates`, na Podi mpya zitaambatanishwa tena kiotomatiki na zilizopo `data-postgres-0` PVCs.

Ninawezaje kupata faili ndani ya Docker overlay2 saraka wakati kontena inakataa kuanza (CrashLoopBackOff / Exited (1))?¶

Usifute kontena iliyoanguka. Muda tu chombo kilichosimamishwa bado kipo ndani `docker ps -a`, safu yake inayoweza kuandikwa na vipandikizi vya kiasi ni sawa kabisa kwenye diski. Unaweza kunakili faili moja kwa moja kutoka kwa kontena iliyosimamishwa ukitumia `docker cp :/var/lib/postgresql/data /root/rescued_data`, au tafuta mwenyeji wake haswa `overlay2` njia kwa kukimbia `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` na kusoma saraka hiyo moja kwa moja kama `root`.

Nini ikiwa mtu alifuta Kubernetes Namespace (kubectl delete ns prod) na PVC zote zilikuwa nazo reclaimPolicy: Delete kwenye AWS EBS au GCP?¶

Ikiwa kiendesha CSI cha wingu (`ebs.csi.aws.com` au `pd.csi.storage.gke.io`) tayari kutekelezwa `DeleteVolume` kwa sababu `reclaimPolicy` ilikuwa `Delete`, angalia nyavu tatu za usalama za kiwango cha wingu mara moja: (1) angalia **AWS Recycle Bin for EBS Volumes** katika console ya AWS EC2 (ikiwa sheria ya uhifadhi ilikuwa amilifu kwenye akaunti/tagi, kiasi cha EBS kilichofutwa kinakaa kwenye Recycle Bin na kinaweza kurejeshwa kwa kubofya 1); (2) angalia **Nakala za AWS / DLM / GCP Snapshot Ratiba** kwa muhtasari wa hivi majuzi wa sauti otomatiki; na (3) angalia ikiwa hifadhidata yako ilikuwa ikitiririsha WAL/binlogs (`WAL-G`, `pgBackRest`, `Litestream`) kwa ndoo ya S3/GCS.

Miongozo inayohusiana¶

• Disk ya seva 100% imejaa (baiti 0 bila malipo): hifadhidata ya logi ya WAL, mti wa B ulioharibika, na uokoaji wa nafasi sifuri
• Kwa bahati mbaya rm -rf au Shift+Delete kwenye Linux, macOS, au Windows: weka tena mara moja kwa kusoma tu na kuchonga ingizo.
• Mashine pepe ya VMDK, VHDX, na ufisadi wa mnyororo wa qcow2 na uokoaji wa hypervisor
• Ahadi ya Git ya Ajali ya funguo za AWS, faili ya .env, au kitufe cha kibinafsi cha SSH kwa repo ya umma ya GitHub
• Shida ya upangishaji wa wavuti, uhamiaji, na urejeshaji wa chelezo
• Hifadhi rudufu za kompyuta, mkakati wa 3-2-1, na uokoaji wa maafa
• Nambari za dharura kwa nchi

Vyanzo na mwongozo rasmi¶

• Hati Rasmi ya Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Kitu cha Hifadhi Kinachotumika Ulinzi (kubernetes.io/pvc-protection Wakamilishaji), Kurudisha Volumes zinazoendelea (Retain dhidi ya Delete), na Uendeshaji etcd Nguzo za Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Dhibiti Data kwenye Docker: Volumes, Bind Mounts, overlay2 Usanifu wa Kiendeshaji cha Hifadhi, na Rejelea ya Punguza.
• Shirika la Linux Kernel (kernel.org): The /proc Mfumo wa faili (procfs Fungua Urejeshaji wa Maelezo ya Faili kupitia /proc/<pid>/fd/) na Maelezo ya Jarida la Ext4.
• ext4magic Nyaraka za Mradi (ext4magic.sourceforge.net): Inodi ya Uchunguzi na Urejeshaji wa Muamala wa Jarida kwenye Mifumo ya Faili ya Ext3/Ext4.
• Taasisi ya Kitaifa ya Viwango na Teknolojia (NIST) (Marekani): Chapisho Maalum 800-190: Mwongozo wa Usalama wa Kontena la Maombi na Urejeshaji wa Tukio.