Volume Hilberîna Docker an Kubernetes jêbirin: Rizgarkirin docker system prune --volumes, overlay2 Inodes, û etcd Snapshots¶

Running docker compose down -v, docker system prune -a --volumes, docker volume rm, an kubectl delete pvc li ser tabloya termînalê ya çewt di hilberînê de yek ji awayên zûtirîn e ku meriv cildê databasa PostgreSQL, MySQL, MariaDB, Redis, MongoDB, an SQLite zindî paqij bike. Berevajî dîmenên makîneya virtual ewr a ku ber bi qulikek vezîvirandinê ya 7-rojî ve diçin, ajokarê voltaja herêmî ya Docker (/var/lib/docker/volumes/<name>/_data) û Kubernetes local-path / hostPath dabînker tavilê POSIX standard derdixin unlink() û rmdir() rasterast li dijî pergala pelan a bingehîn a Linux-ê bang dike (ext4, XFS, an Btrfs). Her nivîsandina ku li ser wê mêvandarê Linux-ê çêdibe piştî ku ferman qediya dikare blokên databasa azadkirî li ser dîskê binivîsîne. Ger dîska servera we ji sedî 100 dagirtî (0 bytes free) berî ku kesek bezî docker system prune --volumes di panîkê de, şêwir bikin dîska serverê 100% tije, databasa têketina têketinê ya WAL, û vejandina cîhê sifir; ji bo jêbirina pelê Linux-ê ya tazî-metal li derveyî konteynir, binêre rm -rf an Shift-Delete li ser ext4, XFS, APFS, û NTFS-ya qezayî: ji nû ve veqetandin-tenê xwendinê û qutkirina inode û makîneya virtual VMDK, VHDX, û qcow2 zencîra wêneya berteng û rizgarkirina hypervisor. Ger ev qutbûna hilberînê bandorê li lênihêrîna nexweşên nexweşxaneyê, şandina acîl, an pergalên ewlehiya karûbarê giştî bike, bi hejmara xweya acîl ya herêmî re telefon bikin (911 li Dewletên Yekbûyî û Kanada, 112 li seranserê Yekîtiya Ewropayê, 999 li Keyaniya Yekbûyî) an pelrêça me ya kontrol bikin hejmarên acîl.

Vê niha bikin¶

1. ** NEBIN docker compose up -d, systemctl restart docker, an Kubernetes pod ji nû ve saz bikin**: Ji nû ve çêkirina konteynerê an ji nû ve destpêkirina Daemon Docker megabytes nû dinivîse overlay2 metadata, têketinên JSON konteynir, û pelên databasa vala yên nû hatine destpêkirin (initdb) rasterast li ser rast ext4 an XFS blokên ku cildê weya jêbirin saniye berê rûniştibû.
2. ** Ger pêvajoya konteynerê di 5 çirkeyan de kontrol bikin (postgres, mysqld, redis-server, node, python) hîn jî di bîrê de dixebite (ps aux û sudo lsof +L1(PID) ravekerek pelê vekirî digire (FD). Hûn dikarin wan pelan rasterast ji wan kopî bikin /proc/<PID>/fd/ an /proc/<PID>/root/ bi windabûna daneya sifir berî ku konteynir raweste.
3. **Heke konteynir jixwe rawestiyaye û deng hat jêbirin (docker compose down -v an docker system prune --volumes(sudo systemctl stop docker.socket docker.service containerd) Ji ber vê yekê konteynerên paşerojê û kontrolên tenduristiyê nivîsandina têketinê rawestînin /var/lib/docker, paşê yan ji nû ve rakin /var/lib/docker (an jî kok / dabeşkirin) tenê-xwendin (sudo mount -o remount,ro /) an tavilê wêneyek volta ewr a asta blokê bikişîne (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) berî ku dest bi tiştekî bike.
4. ** Ger hûn li Kubernetes in (kubectl delete pvc an kubectl delete namespace), SersistentVolume (PV) ReclaimPolicy (kubectl get pv) yekser **:
5. Ger ku PV hebû persistentVolumeReclaimPolicy: Retain, daneyên we ** nayê jêbirin **: ya PV bi tenê bar kir Released statû û dîska weya ewr (EBS, Azure Disk, Ceph RBD, NFS) ji sedî 100 saxlem e.
6. Heta ku kubectl delete pvc tê de asê maye Terminating, Kubernetes Finalizers (kubernetes.io/pvc-protection) ajokarê CSI-ê ji jêbirina hilanîna bingehîn bigire heya ku her Pod hîn jî PVC-yê referans dike. Heta ku hûn daneyan ji Pod-a xebitandinê kopî nekin, Pod-ê jê nekin.
7. ** Parvekirina blokê ya bingehîn (dd / ddrescue li ser SSH) berî ku bixebite li dîskek derveyî an volga ewr veqetîne ext4magic, extundelete, an PhotoRec**: Tu carî karkerên pelan ên ku pelên derketinê li ser heman dabeşkirina dîskê ya ku hûn jê vedigirin dinivîsin /var/lib/docker/volumes.
8. Ji bo dewleta koma Kubernetes ya xerabûyî an bi xeletî hatî paqij kirin (kubectl delete crd / namespace), raweste kube-apiserver û ya herî dawî ya xwe sererast bikin etcd wêneyek (etcdctl snapshot restore): Ger rewşa komê tê de etcd dema ku cildên hilanîna ewr ên bingehîn hîn jî hene, hate paqij kirin etcd hemî vedigerîne PV, PVC, Secret, û ConfigMap tiştên hevdemî.

Dara biryarê: volume Docker jêbirin, overlay2 layer, an Kubernetes PVC triage¶

Vê nexşerêyê bikar bînin da ku rêça paşvekêşana zero-wendaza herî bilez hilbijêrin li ser bingeha ka pêvajoya konteynerê hîn sax e, gelo deng ji hêla dîska herêmî an hilanîna cloud CSI ve hatî piştgirî kirin, û kîjan mêvandarên pergala pelan e. /var/lib/docker:

flowchart TD
    Start["Daneyên Hilberandinê Piştî Fermana Jêbirina Docker an Kubernetes winda ne"] --> WhichEnv{"Kîjan Platform û Fermandar Wenda Kirin?"}

    WhichEnv -->|"Docker: Konteyner Hîn Dikeve (Pelên Di hundurê Volume / Konteynirê de neyên girêdan)"| ProcRescue["Bi rêya sudo lsof +L1 û /proc/PID/fd/N an /proc/PID/root/ Danasîna Pelên Negirêdayî Vekin Rizgar bikin"]

    WhichEnv -->|"Docker: Konteyner rawestiya û cild hat jêbirin (-v / qut kirin --cild)"| StopDocker["Yekser Bixebitîne: sudo systemctl docker.socket docker konteynir rawestîne"]

    WhichEnv -->|"Kubernetes: kubectl pvc / pv / statefulset / navan jêbirin"| K8sCheck{"Ma Pod Hîn Dikeve AN Ma PVC di Bidawîbûnê de Asteng e?"}

    K8sCheck -->|"Erê: Pod Hîn Dikeve (Finalizer Astengkirina CSI jêbirin)"| K8sExec["Pod Jê Jê NEKIN -> Kubectl exec / pg_dump / tar tavilê li ser stdout biavêje Dîska Herêmî"]
    K8sCheck -->|"Na: Pod Gone -> Kubectl kontrol bikin pv bistînin"| ReclaimCheck{"Polîtîkaya Reclaim PV çi bû?"}

    ReclaimCheck -->|"Bihêle (Rewşa PV = berdan)"| ClearClaimRef["100% Daneyên Intact -> PV biguherînin ku spec.claimRef.uid Rake -> Ji nû ve bi PVC-ya Nû ve girêdin"]
    ReclaimCheck -->|"Jêbirin (EBS EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Cloud CSI Volume an Dîska Mêvandarê Herêmî?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Çopa Vegerînê ya Cloud Console / Wêneyên EBS-ê yên Xweser / Çopa Ceph RBD (rbd trash ls) kontrol bikin"]
    CloudOrLocal -->|"Dîska Nodê ya Herêmî (rêya herêmî / hostPath)"| StopDocker

    StopDocker --> RemountRO["Dabeşkirina Hostê Ji nû ve Bikin Tenê-Tenê Xwendin (Çiya -o ji nû ve, ro) AN Wêneyê Astengkirina Stream li ser SSH"]
    RemountRO --> HostFS{"Kîjan Pergala Pelê Mêvandar e /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Debugfs / ext4magic Journal Inode Vegera Danûstandinan bikar bînin (-demek demkî)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Ji bo SQLite, Postgres Heap, an InnoDB .ibd, Btrfs Roots / xfs_irecover / Neqandina Îmzeya Xweser bikar bînin"]

Qonaxa 1: Çawa Docker û Kubernetes bi rastî cildên li ser dîskê jêbirin¶

Berî ku hûn fermanek vegerandinê bimeşînin, fêm bikin ka daneyên we bi fîzîkî li ser mêvandarê Linux-ê li ku dijîn û fermana jêbirinê bi rastî çi bandor kiriye:

Qonaxa 2: Rizgarkirina pelên databasa vekirî ji konteynirek hê jî dimeşe (/proc/<pid>/fd/)¶

Bisekine: ** konteynir hîn jî niha dixebite?** Bi gelemperî, endezyarek skrîptek koçberiya serîlêdanê, karekî krona paqijkirinê, an manualek dimeşîne rm -rf /var/lib/postgresql/data/* an rm /app/data/production.sqlite3 di hundurê konteynirek xebitandinê de, an peldanka bingehîn a mêvandarê bind-mount jê dike /opt/app/data dema ku konteynir bixwe (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) hîn li ser kar e.

Di Linux de, pelek dema ku ji dîskê nayê jêbirin rm an unlink() tê gotin. Blokên dîskê û inoda wê ** ji sedî 100 veqetandî û xwendinê dimînin ** heya pêvajoya paşîn a ku ravekerek pelê vekirî digire (FD) ji bo wê inode wê digire an jî derdikeve.

Gav 1: Nasnameya Pêvajoya mêvandar bibînin (PID) pêvajoya konteynerê¶

Li ser girêka mêvandarê Linux (ne di hundurê konteynerê de), mêvandar bibînin PID databasa we an pêvajoya serîlêdanê:

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)

Gav 2: Pelên databasa negirêdayî rasterast jê kopî bikin /proc/<PID>/fd/¶

Konteynerê ** nehêlin** an ji nû ve bidin destpêkirin. Dema ku pêvajo hîn jî dimeşe, ravekerên pelê xav rasterast li peldankek ewledar a li ser mêvandarê xwe kopî bikin:

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

Gav 3: Hîn çêtir: Xalek mentiqî ya zindî bimeşînin (pg_dump / mysqldump / .backup) berî ku konteynir FD-yan bigire¶

Ger postgres an mysqld hê jî bi pelên daneyên xwe yên di bîrê de vekirî dimeşe û /proc/<PID>/fd/, pêşî li ser pêwendiya unix an pêwendiya TCP-ê ya heyî dumpek mentiqî ya zindî bimeşînin:

# 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

Qonaxa 3: Vegerandina cildek Dockerê jêbirin ext4 an XFS piştî ku konteynir rawestiya¶

Çi eger hûn bezî docker compose down -v an docker system prune --volumes, ji ber vê yekê konteynir jixwe rawestiyaye û hemî /proc/<pid>/fd/ raveker girtî ne? Naha hûn di pêşbaziyekê de ne li hember nivîsandina dîska paşîn a li ser mêvandarê Linux.

Gav 1: Pergala pelan a mêvandarê Linux di nav 10 çirkeyan de cemidîne¶

1. ** Docker, konteynir, kubelet, û cron tavilê rawestînin** ji ber vê yekê tu konteynir, kontrolkirina tenduristiyê, an rotatorê têketinê baytek din nanivîse. /var/lib/docker:

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

2. ** Kontrol bikin ka kîjan amûr û pergala pelan asteng dike /var/lib/docker**:

   df -Th /var/lib/docker
   

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

3. ** Parçeyê Tenê-Xwendinî ji nû ve bihejînin (an jî wêneyek dabeşkirina xav li ser SSH ji makîneyek din re bişînin)**:
4. Ger /var/lib/docker li ser dabeşkirina xweya taybetî an volga LVM-ê ye (mînak /dev/nvme0n1p2 an /dev/mapper/vg0-docker), wê tavilê tenê-xwendewarî ji nû ve saz bikin:

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

5. Ger /var/lib/docker li ser kokê ye / dabeşkirin (/), biceribînin ku bi kernel Magic SysRq vekêşana kernel tenê-xwendewarê bi zorê bidin dabeşkirin (echo u | sudo tee /proc/sysrq-trigger) an sudo mount -o remount,ro /.
6. Heke hûn li ser VPS-ya ewr in (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Tavilê herin konsoleya weba ewr a xwe û Create Snapshot li ser voltama bloka serverê bikirtînin (an jî amûra bloka xav li ser SSH bişînin serverek duyemîn: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Gav 2: Kontrol bikin ka daneyên we hîn jî di HEWLÊN DIN ê bêpere de rûdine yan na overlay2 layer¶

Berî ku blokên dîskê yên ne veqetandî çêkin, verast bikin ku databasa we bi rastî di çîçekek bind an cildek bi navên cûda de ku sax maye nehatiye hilanîn:

# 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

Gav 3: Vegerandina pelrêçiyên volumanên Docker ên negirêdayî li ser ext4 bi kar tînin ext4 Rojname (ext4magic û debugfs)¶

Dema ku docker volume rm jê dike /var/lib/docker/volumes/<vol_name>/_data li ser an ext4 pergala pelan, ext4 nîşankerên blokê yên rasterast sifir dike (i_block / Rayê darê dirêj) di tabloya inode ya zindî de. Lêbelê, ext4 kovar (inode <8>, bi gelemperî 128 MB to 1024 MB tampon zengila dorhêl) hîn jî kopiyên dîrokî yên tabloyên inode yên tam û blokên pelrêça yên ji berê rast digire. docker compose down -v hat îdam kirin.

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

Run ext4magic li dijî dabeşkirina weya tenê-xwendin (an .img kopiya wêneya wêneyê li ser serverek duyemîn), diyarkirina demjimêrek (-a) ji **5 deqe berî ** tu bezî docker compose down -v an 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

Gav 4: Dema ku kovar pêça bû, pelên SQLite, PostgreSQL, an MySQL InnoDB yên xav çêdikin (XFS an ext4)¶

Ger mêvandar ** bikar tîneXFS** an heke ext4 kovara ku berê li ser nîşangirên inode hatî pêçandin, li dijî wêneya dîska xav xêzkirina îmze û avahî bikar bînin (docker_host_raw.img):

1. ** Ji bo Daneyên SQLite3 (.sqlite, .db - Mînak, Vaultwarden, Nextcloud, Alîkarê Malê, Gitea, Grafana)**: Her databasa SQLite3 bi sernavek ASCII ya 16-byte ya bêkêmasî li byte 0 ya rûpela xweya yekem a 4 kilobyte dest pê dike: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), û mezinahiya rûpela databasa rastîn (Bytes 16..17, bi gelemperî 4096) û mezinahiya databasa tevahî di rûpelan de (Bytes 28..31, jimareya 32-bit a mezin-endî) rast di hundurê heman sernivîsê de.
2. Run PhotoRec bi [File Opt] -> [x] sqlite çalak kirin, an dabeşkirinê rasterast pê bişopînin grep -ab "SQLite format 3" ji bo ku hûn pelê SQLite-ya xweya jêbirkirî guheztina baytê ya rastîn bibînin û jê derxin dd:

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

   Carekê derxistin, birevin sqlite3 carved.db ".recover" | sqlite3 repaired.db ji nû ve avakirina her rûpela pelê B-dara saxlem.

1. ** Ji bo MySQL / MariaDB InnoDB (.ibd pelên tabloyê)**: Her InnoDB .ibd tablo ji rêzikan pêk tê 16 KB (16,384 byte) rûpelên ku tê de hene FIL_PAGE_INDEX (0x45BF) sernivîs û tabloya yekta space_id. Percona / TwinDB bikar bînin undrop-for-innodb (stream_parser + c_parser) toolkit ji bo şopandinê /dev/nvme0n1p1 ji bo hemûyan 16 KB Rûpelên InnoDB navnîş bikin û her rêzek rasterast di pelên TSV/SQL de ji bo ji nû ve îtxalkirinê davêjin.
2. ** Ji bo Pelên Heap PostgreSQL ($PGDATA/base/<db_oid>/<relfilenode>)**: PostgreSQL her tabloyê wekî hevgirtî hilîne 8 KB (8,192 byte) rûpelên qelebalix ên tê de hene PageHeaderData (pd_lower, pd_upper, pd_special). Bikaranîn pg_filedump an pglazarus / pdu ji bo ku herêmên dîskê yên nehatine veqetandin bigerin 8 KB rûpelên ku bi sêwirana sêwirana stûnê ya tabloya we li hev dikin (HeapTupleHeaderData) û rêzan ji nû ve ava bikin.

Qonaxa 4: Kubernetes PVC, PV, û etcd Snapshot Recovery Awarte¶

Li Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), bi şaşîtî jêbirina PersistentVolumeClaim (kubectl delete pvc(kubectl delete ns prod) mîmariyek pir cûda ji Docker-a serbixwe dişopîne.

Senaryo A: PVC nîşan dide Terminating (The Finalizer Lifesaver)¶

Run:

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

Senaryoya B: PVC hat jêbirin, û kubectl get pv PersistentVolume tê de nîşan dide Released dewlet (ReclaimPolicy: Retain)¶

Run:

kubectl get pv

Çawa çêbikin a Released PV Available dîsa di 10 çirkeyan de bi windabûna daneya sifir: 1. Tişta PersistentVolume biguherînin û jêbirin spec.claimRef asteng:

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

Senaryoya C: Vegerandina rewşek koma Kubernetes a paqijkirî ji an etcd wêneyek (etcdctl snapshot restore)¶

Çi eger kesek bezî kubectl delete namespace prod an helm uninstall û 200 manîfestoyên Kubernetes, Veşartî, ConfigMaps, û pênaseyên PV li ser xwe-rêveberî ji holê rakirin. kubeadm, k3s, an RKE2 balafira kontrolê?

1. ** Herî dawîn xwe bibînin etcd wêneyek** (ji hêla xwerû ve tê /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, an plansaziya we /var/backups/etcd/snapshot.db).
2. ** Berî ku dest bi komika zindî bike yekitiya wêneyê verast bikin **:

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

3. ** Raweste kube-apiserver û etcd li ser girê(yên) balafira kontrolê**:
4. Li ser kubeadm (pûtên statîk): Livîn /etc/kubernetes/manifests/kube-apiserver.yaml û /etc/kubernetes/manifests/etcd.yaml demkî ji bo /root/manifests_hold/ so kubelet herdu konteyneran bi paqijî disekine, dûv re vedigere /var/lib/etcd to /var/lib/etcd.bak.
5. Li ser k3s: Birevin sudo systemctl stop k3s û sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** Vegerînin etcd pelrêça daneyan li ser 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. Move etcd.yaml û kube-apiserver.yaml vegere nav /etc/kubernetes/manifests/. Di nav 30 çirkeyan de, kube-apiserver ji nû ve bi vegerandin ve tê girêdan etcd hilanîn û her tiştê ku jêbirin Namespace, Secret, ConfigMap, û PersistentVolume ji nû ve xuya dike.

Qonaxa 5: Zehfkirina cildên Docker û Kubernetes li dijî jêbirina qezayî¶

Gava ku databasa hilberîna we were nûve kirin, van çar parêzvanên mîmarî bicîh bînin da ku yek tîpek CLI nikaribe careke din cildek zindî jê bibe:

• ** Her hilberîna Kubernetes biguherînin StorageClass ji reclaimPolicy: Delete to reclaimPolicy: Retain**: Ji hêla xwerû, Klasên Storage cloud-ê yên çêkirî (gp2, gp3, standard-rwo) default to reclaimPolicy: Delete, tê wateya jêbirina PVC-ê dîska ewr hilweşîne. Afirandin StorageClass bi reclaimPolicy: Retain (an jî PV-yên heyî pêve bikin kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') Ji ber vê yekê jêbirina PVC an Navê cîhê tu carî volga bloka bingehîn jê nake.
• ** AWS EBS Recycle Bin / Bernameyên Snapshot GCP / Velero bi CSI Snapshots çalak bikin **: Çalakkirina AWS EBS Recycle Bin ji 7 heta 30 rojan her cildê EBS-ê jêbirin digire jî heke ajokarê CSI bang bike. DeleteVolume.
• Tu carî bikar neynin docker system prune --volumes di skrîptên paqijkirina otomatîkî de an jî rêvekerên CI/CD-ê: Ger konteynirek databasa hilberînê bi kurtî têk bibe (Exited (1)) tam di wê kêlîkê de karekî kron dimeşe docker system prune -a --volumes -f, Docker cildên xwe yên nenas "nebikaranîn" dihesibîne û wan bi domdarî jê dike. Strip --volumes ji hemî nivîsarên paqijkirinê.
• ** Mountên girêdana mêvandar ên eşkere bikar bînin (/srv/prod_data/postgres:/var/lib/postgresql/data) an databasên birêvebir ên derveyî ji bo barkêşên hilberîna dewletî **: Berevajî /var/lib/docker/volumes/, mazûvaniya derhênerên bind-mount li derve /var/lib/docker/ bi tu carî dest nedan docker compose down -v, docker volume rm, an docker system prune --volumes.

Hejmarên awarte yên herêmî û protokolên ajansê¶

Dema ku konteynerek an jêbirina hilanîna Kubernetes bandorê li operasyonên klînîkî yên nexweşxaneyê, şandina ewlehiya giştî, an daneyên kesane yên birêkûpêk dike, tavilê zêde dibin:

• ** Dewletên Yekbûyî û Kanada **: Dial 911 heke têkçûna koma konteyneran çavdêriya klînîkî ya nexweş, pergalên EHR, an şandina acîl asteng bike. Paqijkirina binesaziya konteynera xerab an bûyerên sîber ji CISA re rapor bikin (1-844-Say-CISA / cisa.gov/report) an Navenda Kanadayî ya Ewlekariya Sîber (1-833-CYBER-88).
• ** Keyaniya Yekbûyî **: Dial 999 ji bo metirsiyên li ser jiyanê an binesaziya NHS ya krîtîk. Li gorî GDPR-ya Keyaniya Yekbûyî, hilweşandina daîmî an windabûna hebûna daneyên kesane bêyî paşvekêşana ku were vegerandin hewce dike ku 72-saetê agahdariyek binpêkirinê binirxîne ICO (0303 123 1113).
• Yekîtiya Ewropî: Dial 112 li hemî welatên endamên Yekîtiya Ewropî. Saziyên di bin Rêbernameya NIS2 de divê di nav 24 demjimêran de ji qutbûnek giran a karûbarê hişyariyek zû ji CSIRT-a xwe ya neteweyî re bişînin, û windabûna daneya kesane ya daîmî di nav 72 demjimêran de raporkirina GDPR-Benda 33 radigihîne.
• Australya û Zelanda Nû: Dial 000 li Avusturalya an 111 li Zelanda Nû; bûyerên binesaziyê yên krîtîk ji ACSC re rapor bikin (1300 CYBER1).
• ** Hindistan û Asya-Pasîfîk **: Dial 112 li Hindistanê ji bo bersiva acîl; bûyerên ewlekariya ewr an konteynerê ji CERT-In (incident@cert-in.org.in) di pencereya mecbûrî ya 6 saetan de.

Pirsên pir caran têne pirsîn¶

Dike docker compose down -v mountên girêdanê yên mêvandar jêbirin (./data:/var/lib/mysql) an tenê cildên Named û Anonîm Docker?¶

`docker compose down -v` TENÊ cildên bi navkirî yên ku di nav de hatine ragihandin jêbirin `volumes:` beşa `docker-compose.yml` û cildên Anonîm bi konteyniran ve hatine girêdan; ew qet pelên di hundurê mountek girêdana mêvandar de jêdibe (wek mînak `- /opt/mysql_data:/var/lib/mysql` an `- ./postgres_data:/var/lib/postgresql/data`). Ger pela berhevoka we rêyek mêvandar bikar anî ku bi dest pê dike `/` an `./`, wê peldanka li ser mêvandarê rastê kontrol bikin: pelên we hîn ji sedî 100 saxlem in.

Çima kir docker system prune --volumes Gava ku min tenê 2 hûrdeman konteynir rawestand da ku guhêrbarek jîngehê nûve bike, hêjmara databasa xwe jê bibe?¶

Bi baldarî li ferqa di navbera xwe de bisekinin `docker stop` û `docker rm`: heke konteynir bi tenê be `Stopped / Exited` (tê dîtin `docker ps -a`), `docker system prune --volumes` dike ne cildên wê jêbirin ji ber ku konteynera rawestandin hîn jî wan referans dike. Lêbelê, heke hûn bezîn `docker rm ` (ji bo ku konteynerê bi alayên nû ji nû ve biafirînin) an heke hûn derbas bûne `docker system prune -a --volumes` (ku pêşî hemî konteynerên rawestandî jê dike û paşê hemî cildên ku êdî bi tu konteynerê ve girêdayî ne jêdibe), cild di milliseconda ku konteynera rawestandî hat rakirin û di cih de hat paqij kirin "dang" bû.

Ma ez dikarim di hundurê Docker Desktop-ê de li ser Mac-ê cildek Docker-ê jêbirin vegerim (Apple Silicon / Intel) an Windows (WSL2)?¶

Erê, heke hûn tavilê dev ji Docker Desktop berdin da ku makîneya virtual raweste `fstrim` li dijî dîska virtual. Li ser macOS, Docker hemî cildên Linux di hundurê xwe de hilîne `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; li ser Windows WSL2, hundur `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Wê kopî bikin `.raw` an `.vhdx` pelê tavilê li SSD-ya derveyî, wê di Linux-ê de tenê-xwendewarî ve girêbide (bikaranîna `losetup -Pr` ji bo `.raw` an `qemu-nbd -r` ji bo `.vhdx`), û birevin `ext4magic` an `PhotoRec` dijî virtual `ext4` dabeşkirina hundir.

Heke min bi Kubernetes StatefulSet jêbirin kubectl delete statefulset postgres? Ma wê PVCyên min jî jêbirin?¶

No. Bi xwerû di Kubernetes de (heke `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` bi eşkereyî li ser Kubernetes 1.27+ hate mîheng kirin), dimeşîne `kubectl delete statefulset` kontrolker StatefulSet û Podên wê jê dike, hemû hiştin `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) û daneyên wan ên bingehîn ji sedî 100 saxlem in. Tenê xwe ji nû ve bicîh bikin `StatefulSet` YAML bi heman navî û `volumeClaimTemplates`, û Podên nû dê bixweber bi ya heyî ve ji nû ve werin girêdan `data-postgres-0` PVCs.

Ez çawa xwe bigihînim pelên hundurê Docker overlay2 pelrêça dema ku konteynir dest pê nake (CrashLoopBackOff / Exited (1))?¶

Konteynirê têkçûyî jê nekin. Heya ku konteynera rawestandin hîn jî tê de heye `docker ps -a`, tebeqeya wê ya binivîsandî û çiqilên wê bi tevahî li ser dîskê saxlem in. Hûn dikarin pelan rasterast ji konteynera rawestandî bi kar bînin kopî bikin `docker cp :/var/lib/postgresql/data /root/rescued_data`, an jî mêvandarê wê yê rast bibînin `overlay2` rê bi bezê `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` û xwendina wê pelrêça rasterast wekî `root`.

Ger kesek Kubernetes jêbirin çi dibe Namespace (kubectl delete ns prod) û hemî PVC hebûn reclaimPolicy: Delete li ser AWS EBS an GCP?¶

Ger ajokera CSI ya ewr (`ebs.csi.aws.com` an `pd.csi.storage.gke.io`) jixwe hatine bicihkirin `DeleteVolume` ji ber ku `reclaimPolicy` bû `Delete`, sê tevnên ewlehiyê yên asta ewr tavilê kontrol bikin: (1) **AWS Recycle Bin ji bo Volumên EBS** di konsolê AWS EC2 de kontrol bikin (heke qaîdeyek ragirtinê li ser hesab/etîketan çalak bû, volga EBS-a jêbirin li Recycle Bin rûniştiye û dikare bi 1 klîk ve were sererast kirin); (2) ** AWS Backup / DLM / GCP Snapshot Schedules ** ji bo wêneya herî dawî ya cildê ya otomatîkî kontrol bikin; û (3) kontrol bikin ka databasa we weşana WAL/binlogan bû (`WAL-G`, `pgBackRest`, `Litestream`) ji kelek S3/GCS re.

rêberên Related¶

• Dîska serverê 100% tije (0 bytes belaş): databasa têketina têketinê ya WAL, dara B ya xerabûyî, û vegerandina cîhê sifir
• Li Linux, macOS, an Windows-ê "rm -rf" an "Shift+Delete" ya tesadufî: ji nû ve rakirina yekser-tenê xwendinê û qutkirina inode
• Makîneya virtual VMDK, VHDX, û qcow2 zencîra wêneya berteng û rizgarkirina hîpervisor
• Kombûna Git-ya Tesadufî ya bişkokên AWS, pelê .env, an mifteya SSH ya taybet ji bo depoya GitHub ya giştî
• Krîza mêvandariya malperê, koçberî, û sererastkirina hilanînê
• Piştgiriya komputerê, stratejiya 3-2-1, û başkirina karesatê
• Hejmarên awarte li gorî welat

Çavkanî û rêbernameya fermî¶

• Belgekirina Fermî ya Kubernetes (kubernetes.io / Cloud Native Computing Weqfa): Tişta hilanînê di Parastinê de (kubernetes.io/pvc-protection Finalizers), Vegerandina Volumên Persistent (Retain vs. Delete), û Operating etcd Komên ji bo Kubernetes (etcdctl snapshot restore).
• Docker Inc.docs.docker.com): * Daneyên di Docker de bi rêve bibin: Volume, Bind Mounts, overlay2 Storage Driver Architecture, and Prune Reference*.
• Rêxistina Kernel Linux (kernel.org): * The /proc Pergala Pelan (procfs Bi navgîniya Vegerandina Danasîna Pelê vekin /proc/<pid>/fd/) û Specification Journal Ext4 *.
• ext4magic Belgekirina Projeyê (ext4magic.sourceforge.net): * Li ser Pergalên Pelê Ext3/Ext4 Vegerandina Danûstandina Inode û Rojnamegerî *.
• Enstîtuya Neteweyî ya Standard û Teknolojiyê (NIST) (Dewletên Yekbûyî): Weşana Taybet 800-190: Rêbernameya Ewlekariya Konteynirê ya Serlêdanê & Vegerandina Bûyerê.