Docker ukon Kubernetes Production Volume Gindula: Pagluwas docker system prune --volumes, overlay2 Inodes, kag etcd Mga Snapshot¶

Nagadalagan docker compose down -v, docker system prune -a --volumes, docker volume rm, ukon kubectl delete pvc sa sayop nga terminal tab sa produksyon isa sa pinakamadasig nga paagi sa pagpanas sang live PostgreSQL, MySQL, MariaDB, Redis, MongoDB, ukon SQLite database volume. Indi pareho sa mga snapshot sang cloud virtual machine nga nagasaylo sa 7-adlaw nga recycle bin, ang lokal nga volume driver sang Docker (/var/lib/docker/volumes/<name>/_data) kag Kubernetes local-path / hostPath ang mga probisyoner gilayon nga nag-isyu sang sulundan nga POSIX unlink() kag rmdir() nagatawag sing direkta batok sa nagapaidalom nga Linux host filesystem (ext4, XFS, ukon Btrfs). Ang tagsa ka pagsulat nga nagakatabo sa Linux host pagkatapos matapos ang sugo mahimo mag-overwrite sang nahilway nga mga bloke sang database sa disk. Kon ang imo server disk napuno sing 100 porsyento (0 bytes free) antes may nagdalagan docker system prune --volumes sa kakugmat, magpakonsulta server disk 100% puno, database WAL log bloat, kag zero-space recovery; para sa bare-metal nga mga pagdula sang Linux file sa guwa sang mga suludlan, tan-awa aksidente nga rm -rf ukon Shift-Delete sa ext4, XFS, APFS, kag NTFS: read-only remount kag inode carving kag virtual machine VMDK, VHDX, kag qcow2 snapshot chain corruption kag hypervisor rescue. Kon ini nga pag-untat sang produksyon nagaapektar sa pag-atipan sa pasyente sa ospital, pagpadala sa emerhensya, ukon mga sistema sa kaluwasan sang publiko nga utility, tawga ang imo lokal nga numero sang emerhensya (911 sa Estados Unidos kag Canada, 112 sa bug-os nga European Union, 999 sa United Kingdom) ukon tan-awa ang amon direktoryo sang mga numero sang emerhensya.

Himua ini subong¶

1. INDI magdalagan docker compose up -d, systemctl restart docker, ukon i-redeploy ang Kubernetes pod: Ang paghimo liwat sang suludlan ukon pag-restart sang Docker daemon nagasulat sang mga megabyte sang bag-o overlay2 metadata, container JSON logs, kag bag-o lang gin-initial nga wala unod nga mga file sang database (initdb) direkta sa ibabaw sang eksakto ext4 ukon XFS mga bloke sa diin ang imo ginpanas nga volume nagapungko sang nagligad nga mga segundo.
2. Tan-awa sa sulod sang 5 ka segundo kon ang proseso sang suludlan (postgres, mysqld, redis-server, node, python) nagapadayon gihapon sa memorya (ps aux kag sudo lsof +L1): Kon may isa nga nagpanas sang mga file sa sulod sang isa ka gin-mount nga volume ukon nag-unlink sang isa ka anonymous volume samtang ang suludlan nagalakat pa, ang Linux kernel nagahupot sang 100 porsyento sang mga unlink nga mga file sang database nga buhi sa disk basta ang host Process ID sang container (PID) nagahupot sang isa ka bukas nga file descriptor (FD). Mahimo mo kopyahon ina nga mga file sing direkta gikan sa /proc/<PID>/fd/ ukon /proc/<PID>/root/ nga wala sing pagkadula sang datos antes mag-untat ang suludlan.
3. Kon ang suludlan nauntat na kag ang kadamuon ginpanas (docker compose down -v ukon docker system prune --volumes), i-freeze ang host disk nagasulat gilayon: Pauntata ang Docker daemon (sudo systemctl stop docker.socket docker.service containerd) gani ang mga background container kag mga healthcheck nagauntat sa pagsulat sang mga log sa /var/lib/docker, dayon mag-remount /var/lib/docker (ukon ang gamot / partisyon) read-only (sudo mount -o remount,ro /) ukon magkuha sang gilayon nga block-level cloud volume snapshot (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) antes magtandog sang bisan ano.
4. Kon yara ka sa Kubernetes (kubectl delete pvc ukon kubectl delete namespace), tan-awa ang PersistentVolume (PV) ReclaimPolicy (kubectl get pv) gilayon:
5. Kon ang PV may persistentVolumeReclaimPolicy: Retain, ang imo datos wala ginpanas: ang PV ginsaylo lang sa Released status kag ang imo cloud disk (EBS, Azure Disk, Ceph RBD, NFS) 100 porsyento nga wala maano.
6. Bisan pa kon kubectl delete pvc naipit sa Terminating, Kubernetes Finalizers (kubernetes.io/pvc-protection) punggan ang CSI driver sa pagdula sang underlying storage basta ang bisan ano nga Pod nagapatuhoy gihapon sa sina nga PVC. Indi pag-delete ang Pod tubtob nga makopya mo ang data sa nagadalagan nga Pod.
7. Imahe ang nagapaidalom nga partisyon sang bloke (dd / ddrescue sa SSH) sa isa ka eksternal nga disk ukon separado nga cloud volume antes magdalagan ext4magic, extundelete, ukon PhotoRec: Indi gid magpadalagan sang mga file carver nga nagasulat sang mga output file sa pareho nga partisyon sang disk nga imo ginabawian /var/lib/docker/volumes.
8. Para sa nahalitan ukon aksidente nga ginpanas nga estado sang cluster sang Kubernetes (kubectl delete crd / namespace), mag-untat kube-apiserver kag ibalik ang imo pinakaulihi etcd snapshot (etcdctl snapshot restore): Kon ang estado sang cluster sa etcd ginpanas samtang ang mga volume sang pagtipig sa panganod sa idalom nagaluntad pa, nga nagapanumbalik etcd nabawi ang tanan PV, PVC, Secret, kag ConfigMap mga butang sing dungan.

Desisyon nga kahoy: ginpanas nga Docker volume, overlay2 layer, ukon Kubernetes PVC triage¶

Gamita ini nga flowchart sa pagpili sang pinakamadasig nga zero-loss recovery path base sa kon bala ang proseso sang suludlan buhi pa, kon bala ang volume ginsuportahan sang lokal nga disk ukon cloud CSI storage, kag kon diin nga filesystem ang naga-host /var/lib/docker:

flowchart TD
    Start["Data sang Produksyon Nadula Pagkatapos sang Docker ukon Kubernetes Delete Command"] --> WhichEnv{"Ano nga Plataporma kag Sugo ang Nagtuga sang Pagkadula?"}

    WhichEnv -->|"Docker: Container Nagapadayon Pa (Mga File nga Wala Na-link sa Sulod sang Volume/Container)"| ProcRescue["Luwasa ang Bukas nga Unlinked File Descriptors paagi sa sudo lsof +L1 kag /proc/PID/fd/N ukon /proc/PID/root/"]

    WhichEnv -->|"Docker: Container Stopped & Volume Deleted (compose down -v / prune --volumes)"| StopDocker["Imediate Run: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Kubernetes: kubectl delete pvc / pv / statefulset / namespace"| K8sCheck{"Nagadalagan Pa Bala ang Pod UKON Natak-an Bala ang PVC sa Pagtapos?"}

    K8sCheck -->|"Huo: Ang Pod Nagadalagan Pa (Ang Finalizer Nagabalabag sa CSI Delete)"| K8sExec["INDI Pag-delete ang Pod -> Padalagana ang kubectl exec / pg_dump / tar sa ibabaw sang stdout sa Local Disk Gilayon"]
    K8sCheck -->|"Indi: Pod Gone -> Tan-awa ang kubectl makakuha sang pv"| ReclaimCheck{"Ano ang PV ReclaimPolicy?"}

    ReclaimCheck -->|"Ipadayon (PV Status = Ginpaguwa)"| ClearClaimRef["100% Data Intact -> I-edit ang PV para makuha ang spec.claimRef.uid -> I-re-bind sa New PVC"]
    ReclaimCheck -->|"Panason (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Cloud CSI Volume ukon Local Host Disk?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Tan-awa ang Cloud Console Recycle Bin / Automated EBS Snapshots / Ceph RBD Trash (rbd trash ls)"]
    CloudOrLocal -->|"Local Node Disk (local-path / hostPath)"| StopDocker

    StopDocker --> RemountRO["I-remount ang Host Partition Read-Only (mount -o remount,ro) OR Stream Block Image sa SSH"]
    RemountRO --> HostFS{"Ano nga Filesystem Hosts /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Gamita ang debugfs / ext4magic Journal Inode Transaction Rollback (-a timestamp)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Gamita ang Btrfs Roots / xfs_irecover / Custom Signature Carving para sa SQLite, Postgres Heap, ukon InnoDB .ibd"]

Phase 1: Paano ang Docker kag Kubernetes aktuwal nga nagapanas sang mga tomo sa disk¶

Antes magpadalagan sang bisan ano nga recovery command, hangpa kon diin ang imo data nagapuyo sa Linux host kag kon ano ang aktuwal nga natandog sang delete command:

Phase 2: Pagluwas sang bukas nga mga file sang database gikan sa isa ka nagapadayon nga suludlan (/proc/<pid>/fd/)¶

Hulat: nagadalagan pa bala ang suludlan subong? Sa masami, ang isa ka enhinyero nagapadalagan sang isa ka script sa pagsaylo sang aplikasyon, isa ka trabaho sa pagtinlo sang cron, ukon isa ka manwal rm -rf /var/lib/postgresql/data/* ukon rm /app/data/production.sqlite3 sa sulod sang nagadalagan nga suludlan, ukon nagapanas sang nagapaidalom nga host bind-mount folder /opt/app/data samtang ang suludlan mismo (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) nagapadayon gihapon.

Sa Linux, ang isa ka file wala ginapanas gikan sa disk kon rm ukon unlink() ginatawag. Ang mga bloke sang disk kag inode sini nagapabilin nga 100 porsyento nga gin-alokar kag mabasa tubtob sa katapusan nga proseso nga nagahupot sang isa ka bukas nga file descriptor (FD) sa sina nga inode nagasira sini ukon nagaguwa.

Tikang 1: Pangitaa ang host Process ID (PID) sang proseso sang suludlan¶

Sa Linux host node (indi sa sulod sang suludlan), pangitaa ang host PID sang imo database ukon proseso sang aplikasyon:

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)

Tikang 2: Kopyaha ang wala ma-link nga mga file sang database gikan sa /proc/<PID>/fd/¶

Indi indi pag-untaton ukon i-restart ang suludlan. Samtang nagapadayon pa ang proseso, kopyahon ang mga raw file descriptor direkta sa isa ka luwas nga folder sa imo host:

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

Tikang 3: Mas maayo pa: Magpadalagan sang live logical dump (pg_dump / mysqldump / .backup) antes magsira ang suludlan sang mga FD¶

Kon postgres ukon mysqld nagapadayon gihapon nga ang iya mga data file bukas sa memorya kag /proc/<PID>/fd/, tilawi anay ang pagpadalagan sang isa ka live logical dump sa nagaluntad nga unix socket ukon TCP nga koneksyon:

# 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

Phase 3: Pagbawi sang nadula nga Docker volume sa ext4 ukon XFS pagkatapos nga nag-untat ang suludlan¶

Ano abi kon magdalagan ka docker compose down -v ukon docker system prune --volumes, gani ang suludlan nauntat na kag tanan /proc/<pid>/fd/ ang mga deskriptor sirado? Karon yara ka sa isa ka palumba batok sa background disk writes sa Linux host.

Tikang 1: I-freeze ang Linux host filesystem sa sulod sang 10 segundos¶

1. Untati gilayon ang Docker, containerd, kubelet, kag cron agud wala sing container, healthcheck, ukon log rotator nga nagasulat sang isa pa ka byte sa /var/lib/docker:

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

2. Tan-awa kon ano nga block device kag filesystem ang naga-uyat /var/lib/docker:

   df -Th /var/lib/docker
   

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

3. I-remount ang partisyon nga Read-Only (ukon i-stream ang isa ka hilaw nga laragway sang partisyon paagi sa SSH pakadto sa isa pa ka makina):
4. Kon /var/lib/docker yara sa iya kaugalingon nga dedikado nga partisyon ukon LVM nga kadamuon (halimbawa /dev/nvme0n1p2 ukon /dev/mapper/vg0-docker), i-remount ini read-only gilayon:

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

5. Kon /var/lib/docker yara sa gamot / partisyon (/), tilawi nga piliton ang root partition read-only gamit ang kernel Magic SysRq trigger (echo u | sudo tee /proc/sysrq-trigger) ukon sudo mount -o remount,ro /.
6. Kon yara ka sa isa ka cloud VPS (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Kadto gilayon sa imo cloud web console kag i-klik ang Create Snapshot sa block volume sang server (ukon i-stream ang raw block device paagi sa SSH sa ikaduha nga server: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Tikang 2: Tan-awa kon ang imo datos yara gihapon sa ISA pa ka wala ma-prune nga volume ukon overlay2 layer¶

Antes mag-ukit sang wala gin-alokar nga mga bloke sang disk, i-verify nga ang imo database wala gid gintago sa isa ka bind mount ukon sa isa ka tuhay nga ngalan nga volume nga nakalampuwas:

# 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

Tikang 3: Pagbawi sang wala ma-link nga mga direktoryo sang Docker volume sa ext4 gamit ang ext4 Journal (ext4magic kag debugfs)¶

San-o docker volume rm nagapanas /var/lib/docker/volumes/<vol_name>/_data sa isa ka ext4 sistema sang file, ext4 naga-zero out sang direkta nga mga pointer sang bloke (i_block / extent tree root) sa live inode table. Apang, ang ext4 journal (inode <8>, sa masami 128 MB sa 1024 MB circular ring buffer) nagahupot gihapon sang makasaysayan nga mga kopya sang eksakto nga mga lamesa sang inode kag mga bloke sang direktoryo halin sa wala pa docker compose down -v ginpatay.

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

Dalagan ext4magic batok sa imo read-only nga partisyon (ukon ang .img snapshot copy sa ikaduha nga server), nga nagatumod sang timestamp (-a) halin sa 5 minutos antes ka nagdalagan docker compose down -v ukon 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

Tikang 4: Pag-ukit sang hilaw nga SQLite, PostgreSQL, ukon MySQL InnoDB nga mga file kon ang journal nakaputos na (XFS ukon ext4)¶

Kon ang host nagagamit sang XFS ukon kon ang ext4 journal nga naputos na sa ibabaw sang mga pointer sang inode, gamita ang pirma kag pag-ukit sang istruktura batok sa hilaw nga laragway sang disk (docker_host_raw.img):

1. Para sa SQLite3 Databases (.sqlite, .db - e.g., Vaultwarden, Nextcloud, Home Assistant, Gitea, Grafana): Ang tagsa ka SQLite3 database nagasugod sa isa ka indi masaypan nga 16-byte ASCII header sa byte 0 sang iya una nga 4 kilobyte nga pahina: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0"), kag nagatipig sang eksakto nga kadakuon sang pahina sang database (Bytes 16..17, sa masami 4096) kag kabug-usan nga kadakuon sang database sa mga pahina (Bytes 28..31, big-endian 32-bit integer) sa sulod mismo sang amo man nga header.
2. Dalagan PhotoRec nga may [File Opt] -> [x] sqlite gin-enable, ukon i-scan ang partisyon sing direkta gamit ang grep -ab "SQLite format 3" sa pagpangita sang eksakto nga byte offset sang imo gindula nga SQLite file kag kuhaon ini gamit ang dd:

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

   Kon makuha na, magdalagan sqlite3 carved.db ".recover" | sqlite3 repaired.db sa pagtukod liwat sang tagsa ka wala maano nga pahina sang dahon sang B-tree.

1. Para sa MySQL / MariaDB InnoDB (.ibd mga file sang lamesa): Ang tagsa ka InnoDB .ibd ang lamesa ginabug-usan sang sunud-sunod 16 KB (16,384 byte) nga mga pahina nga nagaunod sang FIL_PAGE_INDEX (0x45BF) header kag ang pinasahi sang lamesa space_id. Gamita ang Percona / TwinDB undrop-for-innodb (stream_parser + c_parser) toolkit sa pag-scan /dev/nvme0n1p1 para sa tanan 16 KB Ang InnoDB naga-index sang mga pahina kag naga-dump sang tagsa ka laray direkta sa TSV/SQL nga mga file para sa pag-import liwat.
2. Para sa PostgreSQL Heap Files ($PGDATA/base/<db_oid>/<relfilenode>): Ang PostgreSQL nagatago sang tagsa ka lamesa bilang magkatupad 8 KB (8,192 byte) mga pahina sang tinumpok nga may unod PageHeaderData (pd_lower, pd_upper, pd_special). Gamita ang pg_filedump ukon pglazarus / pdu sa pag-scan sang wala gin-alokar nga mga rehiyon sang disk para sa 8 KB mga pahina nga nagasanto sa layout sang tuple sang kolum sang imo lamesa (HeapTupleHeaderData) kag tukuron liwat ang mga laray.

Phase 4: Kubernetes PVC, PV, kag etcd Snapshot Emergency Recovery¶

Sa Kubernetes (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), aksidente nga nagdula sang PersistentVolumeClaim (kubectl delete pvc), isa ka StatefulSet, ukon isa ka bug-os nga Namespace (kubectl delete ns prod) nagasunod sa isa ka tuhay gid nga arkitektura sangsa nagaisahanon nga Docker.

Senario A: Ang PVC nagapakita Terminating (Ang Finalizer Lifesaver)¶

Dalagan:

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

Senario B: Ang PVC gindula, kag kubectl get pv nagapakita sang PersistentVolume sa Released estado (ReclaimPolicy: Retain)¶

Dalagan:

kubectl get pv

Paano maghimo sang Released PV Available liwat sa sulod sang 10 segundos nga wala sing pagkadula sang datos: 1. I-edit ang PersistentVolume nga butang kag panason ang spec.claimRef bloke:

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

Scenario C: Pagpanumbalik sang isa ka ginpanas nga estado sang Kubernetes cluster gikan sa isa ka etcd snapshot (etcdctl snapshot restore)¶

Ano abi kon may nagdalagan kubectl delete namespace prod ukon helm uninstall kag ginpanas ang 200 ka Kubernetes manifests, mga Sekreto, ConfigMaps, kag mga kahulugan sang PV sa isa ka self-managed kubeadm, k3s, ukon RKE2 kontrol nga eroplano?

1. Pangitaa ang imo pinakabag-o etcd snapshot (sa default sa /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, ukon ang imo gintalana /var/backups/etcd/snapshot.db).
2. I-verify ang integridad sang snapshot antes tandugon ang live cluster:

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

3. Mag-untat kube-apiserver kag etcd sa control plane node(s):
4. Sa kubeadm (static pods): Magsaylo /etc/kubernetes/manifests/kube-apiserver.yaml kag /etc/kubernetes/manifests/etcd.yaml temporaryo sa /root/manifests_hold/ gani kubelet nagapauntat sing matinlo sa duha ka suludlan, dayon naga-back up /var/lib/etcd sa /var/lib/etcd.bak.
5. Sa k3s: Dalagan sudo systemctl stop k3s kag sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. Ibalik ang etcd direktoryo sang datos sa 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. Magsaylo etcd.yaml kag kube-apiserver.yaml balik sa /etc/kubernetes/manifests/. Sa sulod sang 30 segundos, kube-apiserver nagakonektar liwat sa ginbalik etcd store kag ang tagsa ka nadula nga Namespace, Secret, ConfigMap, kag PersistentVolume nga butang magapakita liwat.

Phase 5: Pagpatig-a sang mga tomo sang Docker kag Kubernetes batok sa aksidente nga pagdula¶

Sa tion nga mabalik ang imo database sang produksyon, ipatuman ining apat ka architectural guardrails agud ang isa ka CLI typo indi na gid makadula sang live volume liwat:

• Ibag-o ang tagsa ka produksyon sang Kubernetes StorageClass gikan sa reclaimPolicy: Delete sa reclaimPolicy: Retain: Sa default, ang built-in cloud StorageClasses (gp2, gp3, standard-rwo) default sa reclaimPolicy: Delete, nga nagakahulugan nga ang pagdula sang PVC nagaguba sang cloud disk. Maghimo sang StorageClass nga may reclaimPolicy: Retain (ukon i-patch ang nagaluntad nga mga PV nga may kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') gani ang pagdula sang PVC ukon Namespace wala gid nagadula sang nagapaidalom nga kadamuon sang bloke.
• I-enable ang AWS EBS Recycle Bin / GCP Snapshot Schedules / Velero with CSI Snapshots: Ang pag-enable sang AWS EBS Recycle Bin nagahupot sang bisan ano nga nadula nga EBS volume sa sulod sang 7 tubtob 30 ka adlaw bisan pa ang CSI driver nagatawag DeleteVolume.
• Indi gid paggamita docker system prune --volumes sa automated cleanup scripts ukon CI/CD runners: Kon ang isa ka suludlan sang database sang produksyon mag-crash sing makadali (Exited (1)) sa eksakto nga tion nga ang isa ka cron job nagadalagan docker system prune -a --volumes -f, ginakabig sang Docker ang iya mga wala ginhingadlan nga mga tomo nga "wala magamit" kag ginapanas ini sing permanente. Hubo --volumes gikan sa tanan nga mga script sa paglimpyo.
• Gamita ang maathag nga mga host bind mounts (/srv/prod_data/postgres:/var/lib/postgresql/data) ukon mga database nga ginadumalahan sa guwa para sa mga workload sang produksyon nga may estado: Indi pareho /var/lib/docker/volumes/, host bind-mount directories sa guwa /var/lib/docker/ wala gid ginatandog sang docker compose down -v, docker volume rm, ukon docker system prune --volumes.

Mga numero sang emerhensya sa rehiyon kag mga protocol sang ahensya¶

Kon ang isa ka suludlan ukon ang pagdula sang pagtipig sang Kubernetes nagaapektar sa mga operasyon sang ospital, pagpadala sang kaluwasan sang publiko, ukon ginakontrol nga personal nga datos, mag-uswag gilayon:

• Estados Unidos kag Canada: I-dial ang 911 kon ang kapaslawan sang container cluster naga-disable sang pagbantay sang pasyente sa klinika, mga sistema sang EHR, ukon pagpadala sang emerhensya. Ireport ang malisyoso nga pagpahid sang imprastraktura sang suludlan ukon mga insidente sa cyber sa CISA (1-844-Say-CISA / cisa.gov/report) ukon ang Canadian Center for Cyber Security (1-833-CYBER-88).
• United Kingdom: Dial 999 para sa mga pamahog sa kabuhi ukon kritikal nga imprastraktura sang NHS. Sa idalom sang UK GDPR, ang permanente nga pagkaguba ukon pagkadula sang personal nga datos nga wala sing mabawi nga backup nagakinahanglan sang pag-ebalwar sang 72-oras nga abiso sang paglapas sa ICO (0303 123 1113).
• European Union: Dial 112 sa tanan nga mga estado nga katapo sang EU. Ang mga entidad sa idalom sang NIS2 Directive dapat magsumiter sang temprano nga paandam sa ila pungsodnon nga CSIRT sa sulod sang 24 oras sang isa ka grabe nga pag-untat sang serbisyo, kag ang permanente nga pagkadula sang personal nga datos nagatuga sang GDPR Artikulo 33 nga pagreport sa sulod sang 72 ka oras.
• Australia kag New Zealand: Dial 000 sa Australia ukon 111 sa New Zealand; ireport ang mga kritikal nga insidente sa imprastraktura sa ACSC (1300 CYBER1).
• India kag Asia-Pacific: Dial 112 sa India para sa emerhensya nga sabat; ireport ang mga insidente sa seguridad sa panganod ukon suludlan sa CERT-In (incident@cert-in.org.in) sa sulod sang mandatory nga 6-oras nga bintana.

Masami nga ginapamangkot¶

Bala docker compose down -v papason ang mga host bind mounts (./data:/var/lib/mysql) ukon Named kag Anonymous Docker volumes lang?¶

`docker compose down -v` GINAPANAS LAMANG ang mga ginhingadlan nga mga tomo nga gindeklarar sa `volumes:` seksyon sang `docker-compose.yml` kag Anonymous nga mga tomo nga nalakip sa mga suludlan; ini wala gid nagapanas sang mga file sa sulod sang host bind mount (subong sang `- /opt/mysql_data:/var/lib/mysql` ukon `- ./postgres_data:/var/lib/postgresql/data`). Kon ang imo compose file naggamit sang host path nga nagasugod sa `/` ukon `./`, tan-awa ina nga folder sa host subong: ang imo mga file 100 porsyento pa nga wala maano.

Ngaa docker system prune --volumes panason ang akon kadamuon sang database sang gin-untat ko lang ang suludlan sa sulod sang 2 ka minutos sa pag-update sang isa ka environment variable?¶

Hulaton sing maayo ang kinatuhayan sa ulot sang `docker stop` kag `docker rm`: kon ang isa ka suludlan amo lamang `Stopped / Exited` (makita sa `docker ps -a`), `docker system prune --volumes` nagahimo indi panason ang mga tomo sini bangod ang gin-untat nga suludlan nagapatuhoy gihapon sa ila. Apang, kon nagdalagan ka `docker rm ` (sa paghimo liwat sang suludlan nga may bag-o nga mga bandera) ukon kon nakapasar ka `docker system prune -a --volumes` (nga una nga nagapanas sang tanan nga gin-untat nga mga suludlan kag dayon ginapanas ang tanan nga mga tomo nga wala na nagalakip sa bisan ano nga suludlan), ang tomo nangin "nagabitay" sa millisecond nga ang nag-untat nga suludlan ginkuha kag ginpanas gilayon pagkatapos sini.

Mahimo ko bala mabawi ang isa ka nadula nga Docker volume sa sulod sang Docker Desktop sa isa ka Mac (Apple Silicon / Intel) ukon mga bintana (WSL2)?¶

Huo, kon mag-untat ka gilayon sa Docker Desktop agud ang virtual machine mag-untat sa pagdalagan `fstrim` batok sa virtual disk. Sa macOS, ginatago sang Docker ang tanan nga mga tomo sang Linux sa sulod `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; sa Windows WSL2, sa sulod `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Kopyaha ina `.raw` ukon `.vhdx` file sa isa ka external SSD gilayon, ilakip ini read-only sa Linux (gamit ang `losetup -Pr` para sa `.raw` ukon `qemu-nbd -r` para sa `.vhdx`), kag magdalagan `ext4magic` ukon `PhotoRec` batok sa virtual `ext4` partisyon sa sulod.

Ano abi kon ginpanas ko ang isa ka Kubernetes StatefulSet nga may kubectl delete statefulset postgres? Gindula man bala sini ang akon mga PVC?¶

Indi. Sa default sa Kubernetes (luwas kon `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` maathag nga gin-configure sa Kubernetes 1.27+), nga nagadalagan `kubectl delete statefulset` ginapanas ang StatefulSet controller kag ang mga Pod sini, ginabiyaan ang tanan `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) kag ang ila mga datos nga 100 porsyento nga wala maano. I-apply lang liwat ang imo `StatefulSet` YAML manifest nga may pareho nga ngalan kag `volumeClaimTemplates`, kag ang bag-o nga mga Pod awtomatiko nga maga-attach liwat sa nagaluntad na `data-postgres-0` Mga PVC.

Paano ko ma-access ang mga file sa sulod sang Docker overlay2 direktoryo kon ang suludlan magdumili sa pagsugod (CrashLoopBackOff / Exited (1))?¶

Ayaw pagtangtang ang nahugno nga suludlan. Basta ang nauntat nga suludlan nagaluntad gihapon sa `docker ps -a`, ang iya writable layer kag volume mounts bug-os nga wala maano sa disk. Mahimo ka magkopya sang mga file direkta gikan sa gin-untat nga suludlan gamit ang `docker cp :/var/lib/postgresql/data /root/rescued_data`, ukon pangitaa ang eksakto nga host sini `overlay2` banas paagi sa pagdalagan `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` kag ang pagbasa sina nga direktoryo sing direkta subong `root`.

Ano abi kon may nag-delete sang Kubernetes Namespace (kubectl delete ns prod) kag ang tanan nga PVCs may reclaimPolicy: Delete sa AWS EBS ukon GCP?¶

Kon ang cloud CSI driver (`ebs.csi.aws.com` ukon `pd.csi.storage.gke.io`) napatay na `DeleteVolume` kay `reclaimPolicy` amo `Delete`, tan-awa gilayon ang tatlo ka cloud-level safety nets: (1) tan-awa ang **AWS Recycle Bin para sa EBS Volumes** sa AWS EC2 console (kon ang isa ka retention rule aktibo sa account/tags, ang gindula nga EBS volume nagapungko sa Recycle Bin kag mahimo nga mabalik sa 1 ka pag-klik); (2) tan-awa ang **AWS Backup / DLM / GCP Snapshot Schedules** para sa pinakaulihi nga automated volume snapshot; kag (3) tan-awa kon ang imo database naga-stream sang WAL/binlogs (`WAL-G`, `pgBackRest`, `Litestream`) sa isa ka S3/GCS nga balde.

May kaangtanan nga mga giya¶

• Server disk 100% puno (0 bytes free): database WAL log bloat, corrupted B-tree, kag zero-space recovery
• Aksidente nga rm -rf ukon Shift+Delete sa Linux, macOS, ukon Windows: gilayon nga read-only remount kag inode carving
• Virtual machine VMDK, VHDX, kag qcow2 snapshot chain corruption kag hypervisor rescue
• Aksidente nga Git commit sang AWS keys, .env file, ukon pribado nga SSH key sa publiko nga GitHub repo
• Krisis sa pag-host sang web, paglalin, kag pagpanumbalik sang backup
• Mga backup sa kompyuter, ang 3-2-1 nga estratehiya, kag pagbangon sa kalamidad
• Mga numero sang emerhensya suno sa pungsod

Mga ginhalinan kag opisyal nga giya¶

• Opisyal nga Dokumentasyon sang Kubernetes (kubernetes.io / Cloud Native Computing Foundation): Storage Object in Use Protection (kubernetes.io/pvc-protection Mga Finalizers), Pagbawi sang PersistentVolumes (Retain vs. Delete), kag Pag-operate etcd Mga Cluster para sa Kubernetes (etcdctl snapshot restore).
• Docker Inc. (docs.docker.com): Magdumala sang Data sa Docker: Mga Tomo, Mga Bind Mount, overlay2 Arkitektura sang Driver sang Pagtipig, kag Prune Reference.
• Ang Linux Kernel Organization (kernel.org): Ang /proc Filesystem (procfs Buksi ang File Descriptor Recovery paagi sa /proc/<pid>/fd/) kag Ext4 Journal Specification.
• ext4magic Dokumentasyon sang Proyekto (ext4magic.sourceforge.net): Forensic Inode kag Journal Transaction Recovery sa Ext3/Ext4 Filesystems.
• National Institute of Standards and Technology (NIST) (Estados Unidos): Espesyal nga Publikasyon 800-190: Giya sa Seguridad sang Suludlan sang Aplikasyon kag Pagbawi sang Insidente.