Ҳаҷми истеҳсоли Docker ё Kubernetes нест карда шуд: Наҷотдиҳӣ docker system prune --volumes, overlay2 Inodes, ва etcd Суратҳо¶

Давидан docker compose down -v, docker system prune -a --volumes, docker volume rm, ё kubectl delete pvc дар ҷадвали терминали нодуруст дар истеҳсолот яке аз роҳҳои зудтарини тоза кардани ҳаҷми зиндаи PostgreSQL, MySQL, MariaDB, Redis, MongoDB ё SQLite мебошад. Баръакси аксҳои мошини виртуалии абрӣ, ки ба қуттии партовҳои 7-рӯза мегузаранд, драйвери ҳаҷми маҳаллии Docker (/var/lib/docker/volumes/<name>/_data) ва Кубернетес local-path / hostPath провайдерҳо фавран стандарти POSIX мебароранд unlink() ва rmdir() бевосита бар зидди системаи файлии асосии Linux занг мезанад (ext4, XFS, ё Btrfs). Ҳар як навиштан, ки дар он ҳости Linux пас аз анҷоми фармон ба амал меояд, метавонад блокҳои озодшудаи махзани маълумотро дар диск баргардонад. Агар диски сервери шумо то 100 фоиз пур шавад (0 bytes free) пеш аз он ки касе ran занад docker system prune --volumes дар воҳима, машварат диски сервер 100% пур, пойгоҳи додаҳои WAL ва барқарорсозии фазои сифр; барои нест кардани файлҳои Linux дар берун аз контейнерҳо, нигаред тасодуфӣ rm -rf ё Shift-Delete дар ext4, XFS, APFS ва NTFS: аз нав насб кардани танҳо барои хондан ва кандакории inode ва мошини виртуалии VMDK, VHDX ва qcow2 фасоди занҷири аксбардорӣ ва наҷотдиҳии гипервизор. Агар ин қатъи истеҳсолот ба нигоҳубини беморон дар беморхона, фиристодани ҳолати фавқулодда ё системаҳои бехатарии коммуналӣ таъсир расонад, ба рақами фавқулоддаи маҳаллии худ занг занед (911 дар Иёлоти Муттаҳида ва Канада, 112 дар саросари Иттиҳоди Аврупо, 999 дар Британияи Кабир) ё директорияи моро санҷед рақамҳои фавқулодда.

Ҳоло ин корро кунед¶

1. ** На давидан docker compose up -d, systemctl restart docker, ё аз нав ҷойгиркунии pod Kubernetes**: Аз нав сохтани контейнер ё бозоғоз кардани демони Docker мегабайтҳои нав менависад overlay2 метамаълумот, гузоришҳои JSON контейнер ва файлҳои холии пойгоҳи додаҳои нав оғозшуда (initdb) бевосита аз болои дақиқ ext4 ё XFS блокҳое, ки ҳаҷми ҳазфшудаи шумо чанд сония пеш нишаста буд.
2. Дар 5 сония тафтиш кунед, ки раванди контейнер (postgres, mysqld, redis-server, node, python) дар хотира кор мекунад (ps aux ва sudo lsof +L1): Агар касе файлҳоро дар дохили ҳаҷми васлшуда нест кунад ё ҳаҷми номаълумро ҷудо кунад, ядрои Linux 100 фоизи файлҳои махзани пайвастнашударо дар диск зинда нигоҳ медорад, то он даме, ки ID Раванди хости контейнер (PID) дорои тавсифи файли кушода (FD). Шумо метавонед ин файлҳоро мустақиман аз он нусхабардорӣ кунед /proc/<PID>/fd/ ё /proc/<PID>/root/ бо талафоти сифри маълумот пеш аз қатъ кардани контейнер.
3. Агар контейнер аллакай қатъ шуда бошад ва ҳаҷми ҳазф карда шуда бошад (docker compose down -v ё docker system prune --volumes), ях кардани диски ҳост фавран менависад: Демони Docker-ро қатъ кунед (sudo systemctl stop docker.socket docker.service containerd) аз ин рӯ, контейнерҳои пасзамина ва санҷишҳои саломатӣ навиштани гузоришҳоро ба онҳо қатъ мекунанд /var/lib/docker, пас ё аз нав насб кунед /var/lib/docker (ё реша / қисм) танҳо барои хондан (sudo mount -o remount,ro /) ё акси фаврии ҳаҷми абрро дар сатҳи блок гиред (AWS EBS Snapshot, GCP Persistent Disk Snapshot, DigitalOcean Volume Snapshot) пеш аз ба чизе ламс кардан.
4. Агар шумо дар Kubernetes бошед (kubectl delete pvc ё kubectl delete namespace), PersistentVolume-ро тафтиш кунед (PV) ReclaimPolicy (kubectl get pv) фавран:
5. Агар PV дошт persistentVolumeReclaimPolicy: Retain, маълумоти шумо тоза нашудааст: the PV ба танҳоӣ кӯчид Released вазъ ва диски абрии шумо (EBS, Azure Disk, Ceph RBD, NFS) 100 фоиз солим аст.
6. Ҳатто агар kubectl delete pvc дар ** часпидаастTerminating**, Кубернетес Фализаторҳо (kubernetes.io/pvc-protection) ронандаи CSI-ро аз нест кардани нигаҳдории аслӣ бозмедорад, то даме ки ягон Pod ба PVC ишора мекунад. То он даме, ки маълумотро аз Pod иҷрошаванда нусхабардорӣ накунед, Pod-ро нест накунед.
7. ** Қисмати блоки асосиро тасвир кунед (dd / ddrescue бар SSH) ба диски беруна ё ҳаҷми абрии алоҳида пеш аз кор кардан ext4magic, extundelete, ё PhotoRec**: Ҳеҷ гоҳ кандакориҳои файлро иҷро накунед, ки файлҳои баромадро ба ҳамон қисмати диске, ки шумо аз он барқарор карда истодаед, менависанд /var/lib/docker/volumes.
8. ** Барои ҳолати кластерии вайроншуда ё тасодуфан тозашудаи Kubernetes (kubectl delete crd / namespace), ист kube-apiserver ва охирини худро барқарор кунед etcd аксбардорӣ (etcdctl snapshot restore)**: Агар кластер дар etcd тоза карда шуд, дар ҳоле ки ҳаҷми нигоҳдории абрии аслӣ то ҳол мавҷуд аст ва барқарор карда мешавад etcd ҳамаро барқарор мекунад PV, PVC, Secret, ва ConfigMap объектҳо дар як вақт.

Дарахти қарор: ҳаҷми ҳазфшудаи Docker, overlay2 қабат, ё триажи PVC Kubernetes¶

Ин ҷадвалро истифода баред, то роҳи зудтарини барқарорсозии сифрро дар асоси он, ки оё раванди контейнер ҳанӯз зинда аст, оё ҳаҷм аз ҷониби диски маҳаллӣ ё нигаҳдории абрии CSI пуштибонӣ шудааст ва кадом ҳостҳои системаи файлиро интихоб кунед. /var/lib/docker:

flowchart TD
    Start["Маълумоти истеҳсолӣ пас аз фармони Docker ё Kubernetes нест карда намешавад"] --> WhichEnv{"Кадом Платформа ва Фармон боиси талафот гардид?"}

    WhichEnv -->|"Докер: Контейнер ҳоло ҳам кор мекунад (файлҳое, ки дар дохили ҳаҷм/контейнер пайваст нашудаанд)"| ProcRescue["Тавассути sudo lsof +L1 ва /proc/PID/fd/N ё /proc/PID/root/ Дескрипторҳои кушодаи файлро наҷот диҳед"]

    WhichEnv -->|"Докер: Контейнер қатъ карда шуд ва ҳаҷм нест карда шуд (созиш поён -v / prune --volumes)"| StopDocker["Дарҳол иҷро кунед: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"Кубернетҳо: kubectl нест кардани pvc / pv / statefulset / фазои ном"| K8sCheck{"Оё Pod то ҳол кор мекунад Ё PVC дар қатъ шудан часпидааст?"}

    K8sCheck -->|"Бале: Под ҳоло ҳам кор мекунад (Нинализатори бастани CSI тозакунӣ)"| K8sExec["Pod-ро нест накунед -> kubectl exec / pg_dump / tar -ро дар stdout ба диски маҳаллӣ фавран иҷро кунед"]
    K8sCheck -->|"Не: Pod Gone -> Санҷед kubectl get pv"| ReclaimCheck{"PV ReclaimPolicy чӣ буд?"}

    ReclaimCheck -->|"Нигоҳдорӣ (Вазъи PV = Баровард)"| ClearClaimRef["100% маълумот бетаъхир -> Таҳрири PV барои нест кардани spec.claimRef.uid -> дубора ба PVC нав пайваст кунед"]
    ReclaimCheck -->|"Нест кардан (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"Ҳаҷми абрии CSI ё диски мизбони маҳаллӣ?"}

    CloudOrLocal -->|"Абри CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["Қуттии партови Cloud Console / Snapshots худкори EBS / Ceph RBD Trash (rbd trash ls) -ро санҷед"]
    CloudOrLocal -->|"Диски гиреҳи маҳаллӣ (маҳаллӣ-роҳ / hostPath)"| StopDocker

    StopDocker --> RemountRO["Қисмати ҳостро танҳо барои хондан аз нав насб кунед (mount -o remount,ro) Ё тасвири блоки ҷараёнро тавассути SSH"]
    RemountRO --> HostFS{"Кадом системаи файлиро мизбон /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["Истифода debugfs / ext4magic Journal Inode Transaction Rellback (-як тамғаи вақт)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["Барои SQLite, Postgres Heap ё InnoDB .ibd кандакории Btrfs Roots / xfs_irecover / Custom Signature Carving -ро истифода баред"]

Марҳилаи 1: Чӣ тавр Docker ва Kubernetes воқеан ҳаҷмҳоро дар диск нест мекунанд¶

Пеш аз иҷро кардани ягон фармони барқарорсозӣ, бифаҳмед, ки маълумоти шумо дар мизбони Linux дар куҷо зиндагӣ мекард ва фармони нест кардан воқеан ба чӣ дахл дорад:

Марҳилаи 2: Наҷот додани файлҳои пойгоҳи додаҳо аз як контейнери коркунанда (/proc/<pid>/fd/)¶

Интизор шавед: Оё контейнер ҳоло ҳам кор мекунад? Аксар вақт, муҳандис скрипти муҳоҷирати барнома, кори тозакунии cron ё дастурро иҷро мекунад rm -rf /var/lib/postgresql/data/* ё rm /app/data/production.sqlite3 дар дохили контейнери иҷрошаванда ё папкаи асосии host bind-mount-ро нест мекунад /opt/app/data дар ҳоле ки худи контейнер (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node)оло хам кор карда истодааст**.

Дар Linux, вақте ки файл аз диск нест карда намешавад rm ё unlink() номида мешавад. Блокҳои диск ва иноди он то 100 фоиз ҷудо ва хондашаванда боқӣ мемонанд** то раванди охирини дорои дескриптори файли кушода (FD) ба он иноде онро мебандад ё мебарояд.

Қадами 1: Ҷустуҷӯи ID раванди мизбон (PID) раванди контейнер¶

Дар гиреҳи мизбони Linux (на дар дохили контейнер), мизбонро пайдо кунед PID аз пойгоҳи додаҳо ё раванди дархости шумо:

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)

Қадами 2: Файлҳои махзани пайвастнашударо мустақиман аз он нусхабардорӣ кунед /proc/<PID>/fd/¶

Контейнерро **накунед ва аз нав ба кор андозед. Ҳангоме ки ин раванд идома дорад, тавсифкунандагони файли хомро мустақиман ба ҷузвдони бехатари мизбони худ нусхабардорӣ кунед:

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

Қадами 3: Боз ҳам беҳтар: партови мантиқии зиндаро иҷро кунед (pg_dump / mysqldump / .backup) пеш аз он ки контейнер ФД-ро пӯшонад¶

Агар postgres ё mysqld то ҳол бо файлҳои маълумоташ дар хотира кушода кор мекунад ва /proc/<PID>/fd/, кӯшиш кунед, ки аввал як партови мантиқии зиндаро тавассути васлаки мавҷудаи unix ё пайвасти 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

Марҳилаи 3: Барқарор кардани ҳаҷми ҳазфшудаи Docker фаъол аст ext4 ё XFS пас аз боздоштани контейнер¶

Чӣ мешавад, агар шумо давида бошед docker compose down -v ё docker system prune --volumes, Пас контейнер аллакай истод ва хама /proc/<pid>/fd/ тавсифкунандаҳо бастаанд? Ҳоло шумо дар як мусобиқа бар зидди сабтҳои пасзамина дар мизбони Linux ҳастед.

Қадами 1: Системаи файлии Linux-ро дар давоми 10 сония ях кунед¶

1. Docker, containerd, kubelet ва cron-ро фавран қатъ кунед то ҳеҷ як контейнер, санҷиши саломатӣ ё ротатор ба як байти дигар нанависад. /var/lib/docker:

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

2. ** Санҷед, ки кадом дастгоҳ ва системаи файлии блокро нигоҳ медорад /var/lib/docker**:

   df -Th /var/lib/docker
   

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

3. ** Қисматро барои хондан аз нав насб кунед (ё тасвири қисмати хомро аз SSH ба мошини дигар ҷараён диҳед)**:
4. Агар /var/lib/docker дар қисмати махсуси худ ё ҳаҷми LVM мавҷуд аст (масалан /dev/nvme0n1p2 ё /dev/mapper/vg0-docker), онро фавран барои хондан аз нав насб кунед:

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

5. Агар /var/lib/docker дар реша аст / тақсимот (/), кӯшиш кунед, ки қисмати решавӣ танҳо барои хондан бо истифода аз триггери ядрои Magic SysRq (echo u | sudo tee /proc/sysrq-trigger) ё sudo mount -o remount,ro /.
6. Агар шумо дар VPS абрӣ бошед (AWS EC2, GCP, DigitalOcean, Hetzner, Linode): Дарҳол ба консоли абрии худ равед ва дар ҳаҷми блоки сервер Сохтани акси лаҳзаро клик кунед (ё дастгоҳи блоки хомро тавассути SSH ба сервери дуюм ҷараён диҳед: sudo dd if=/dev/nvme0n1p1 bs=4M status=progress | gzip -1 | ssh user@backup-server "cat > /mnt/storage/docker_host_raw.img.gz").

Қадами 2: Санҷед, ки оё маълумоти шумо то ҳол дар ДИГАР ҳаҷми буриданашуда нишастааст ё overlay2 қабат¶

Пеш аз буридани блокҳои дискҳои ҷудонашуда, санҷед, ки пойгоҳи додаи шумо воқеан дар васлаки баста ё ҳаҷми дигаре, ки зинда мондааст, нигоҳ дошта нашудааст:

# 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

Қадами 3: Барқарор кардани директорияҳои ҳаҷми Docker ҷудонашуда фаъол ext4 бо истифода аз ext4 маҷалла (ext4magic ва debugfs)¶

Кай docker volume rm нест мекунад /var/lib/docker/volumes/<vol_name>/_data дар бораи а ext4 системаи файлӣ, ext4 нишондиҳандаҳои блоки мустақимро сифр мекунад (i_block / васеъ решаи дарахт) дар ҷадвали inode зинда. Аммо, ext4 журнал (inode <8>, маъмулан 128 MB ба 1024 MB буфери ҳалқаи даврашакл) то ҳол нусхаҳои таърихии ҷадвалҳои дақиқи inode ва блокҳои директорияро аз рости пеш нигоҳ медорад docker compose down -v ба қатл расонида шуд.

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

Давидан ext4magic бар зидди қисмати танҳо барои хондани шумо (ё .img нусхаи аксбардорӣ дар сервери дуюм), бо нишон додани тамғаи вақт (-a) аз 5 дакика пеш шумо ran зад docker compose down -v ё 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

Қадами 4: Тартиб додани файлҳои SQLite, PostgreSQL ё MySQL InnoDB ҳангоми печонидани маҷалла (XFS ё ext4)¶

Агар мизбон ** истифода барадXFS** ё агар ext4 маҷаллае, ки аллакай дар болои нишондиҳандаҳои inode печонида шудааст, кандакорӣ кардани имзо ва сохторро бар зидди тасвири диски хом истифода баред (docker_host_raw.img):

1. ** Барои пойгоҳи додаҳои SQLite3 (.sqlite, .db - масалан, Vaultwarden, Nextcloud, Assistant Home, Gitea, Grafana)**: Ҳар як махзани SQLite3 бо сарлавҳаи 16-байтии ASCII дар байт 0 аз саҳифаи аввалини 4 килобайташ оғоз мешавад: 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 ("SQLite format 3\0") ва андозаи дақиқи саҳифаи пойгоҳи додаҳоро нигоҳ медорад (Bytes 16..17, маъмулан 4096) ва ҳаҷми умумии пойгоҳи додаҳо дар саҳифаҳо (Bytes 28..31, адади бузурги 32-битӣ) дар дохили ҳамон сарлавҳа.
2. Давидан PhotoRec бо [File Opt] -> [x] sqlite фаъол, ё скан ҳиҷобест бевосита бо grep -ab "SQLite format 3" Барои дарёфти ҷуброни дақиқи байти файли ҳазфшудаи SQLite ва истихроҷи он бо dd:

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

   Пас аз истихроҷ, давед sqlite3 carved.db ".recover" | sqlite3 repaired.db ки хар як сахифаи барги бехи дарахтро аз нав созад.

1. ** Барои MySQL / MariaDB InnoDB (.ibd файлҳои ҷадвал)**: Ҳар як InnoDB .ibd ҷадвал иборат аст аз пайдарпай 16 KB (16,384 байт) саҳифаҳое, ки дорои FIL_PAGE_INDEX (0x45BF) сарлавҳа ва беназири ҷадвал space_id. Percona / TwinDB-ро истифода баред undrop-for-innodb (stream_parser + c_parser) асбобҳо барои скан /dev/nvme0n1p1 барои ҳама 16 KB Саҳифаҳои индекси InnoDB ва ҳар як сатрро мустақиман ба файлҳои TSV/SQL барои воридоти дубора партоед.
2. ** Барои файлҳои Heap PostgreSQL ($PGDATA/base/<db_oid>/<relfilenode>)**: PostgreSQL ҳар як ҷадвалро ҳамчун ҳамшафат нигоҳ медорад 8 KB (8,192 байт) саҳифаҳои тӯдаро дар бар мегиранд PageHeaderData (pd_lower, pd_upper, pd_special). Истифода pg_filedump ё pglazarus / pdu барои скан кардани минтақаҳои диски ҷудонашуда 8 KB саҳифаҳое, ки ба тарҳбандии сутуни ҷадвали шумо мувофиқанд (HeapTupleHeaderData) ва каторхоро аз нав созанд.

Марҳилаи 4: Kubernetes PVC, PV, ва etcd Барқарорсозии ҳолати фавқулодда¶

Дар Кубернетес (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), тасодуфан нест кардани PersistentVolumeClaim (kubectl delete pvc), StatefulSet ё тамоми фазои ном (kubectl delete ns prod) меъмории хеле гуногунро аз Docker мустақил пайравӣ мекунад.

Сенарияи A: PVC нишон медиҳад Terminating (The Finalizer Lifesaver)¶

Давидан:

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

Сенарияи B: PVC нест карда шуд, ва kubectl get pv PersistentVolume дар нишон медиҳад Released давлат (ReclaimPolicy: Retain)¶

Давидан:

kubectl get pv

Чӣ тавр сохтани а Released PV Available боз дар 10 сония бо талафоти сифр маълумот: 1. Объекти PersistentVolume -ро таҳрир кунед ва нест кунед spec.claimRef блок:

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

Сенарияи C: Барқарор кардани ҳолати кластери тозашудаи Кубернетес аз etcd аксбардорӣ (etcdctl snapshot restore)¶

Чӣ мешавад, агар касе давида бошад kubectl delete namespace prod ё helm uninstall ва 200 манифести Kubernetes, Secrets, ConfigMaps ва таърифҳои PV дар як худидорашаванда нест карда шуд. kubeadm, k3s, ё RKE2 ҳавопаймои идора?

1. ** Навори охирини худро пайдо кунед etcd акси snapshot** (бо нобаёнӣ дар /var/lib/rancher/k3s/server/db/snapshots/, /var/lib/rancher/rke2/server/db/snapshots/, ё нақшаи шумо /var/backups/etcd/snapshot.db).
2. ** Пеш аз ламс кардан ба кластери зинда якпорчагии аксҳоро тафтиш кунед**:

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

3. ** Истед kube-apiserver ва etcd дар гиреҳи ҳавопаймои идоракунӣ**:
4. Дар kubeadm (подҳои статикӣ): Ҳаракат кунед /etc/kubernetes/manifests/kube-apiserver.yaml ва /etc/kubernetes/manifests/etcd.yaml муваққатан ба /root/manifests_hold/ ҳамин тавр kubelet ҳарду контейнерро тоза бозмедорад, сипас бозпас бармегардад /var/lib/etcd ба /var/lib/etcd.bak.
5. Дар k3s: давидан sudo systemctl stop k3s ва sudo k3s server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.
6. ** Барқарор кунед etcd директорияи маълумот дар 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. Ҳаракат etcd.yaml ва kube-apiserver.yaml бозгашт ба /etc/kubernetes/manifests/. Дар давоми 30 сония, kube-apiserver ба барқароршуда пайваст мешавад etcd нигоҳ доред ва ҳар як объекти ҳазфшудаи Номҳо, Сирри, ConfigMap ва PersistentVolume дубора пайдо мешавад.

Марҳилаи 5: Сахтгардонии ҳаҷми Docker ва Kubernetes бар зидди ҳазфи тасодуфӣ¶

Пас аз барқарор кардани махзани истеҳсолии шумо, ин чаҳор паноҳгоҳи меъмориро татбиқ кунед, то як хатои CLI ҳеҷ гоҳ ҳаҷми зиндаро дигар нест карда наметавонад:

• ** Ҳар як истеҳсоли Kubernetes -ро тағир диҳед StorageClass аз reclaimPolicy: Delete ба reclaimPolicy: Retain**: Бо нобаёнӣ, дарунсохти абрии StorageClasses (gp2, gp3, standard-rwo) пешфарз ба reclaimPolicy: Delete, маънои нест кардани PVC диски абрро нест мекунад. Эҷоди а StorageClass бо reclaimPolicy: Retain (ё PV-ҳои мавҷударо бо kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') бинобар ин нест кардани PVC ё Фазои ном ҳеҷ гоҳ ҳаҷми блоки асосиро нест намекунад.
• Даргиронидани қуттии AWS EBS / GCP Snapshot Schedules / Velero бо CSI Snapshots: Фаъол кардани AWS EBS Bin ҳама ҳаҷми ҳазфшудаи EBS-ро аз 7 то 30 рӯз нигоҳ медорад, ҳатто агар ронандаи CSI занг занад DeleteVolume.
• ** Ҳеҷ гоҳ истифода набаред docker system prune --volumes дар скриптҳои автоматии тозакунӣ ё давандагони CI/CD**: Агар контейнери пойгоҳи додаҳои истеҳсолӣ ба таври мухтасар шикаст хӯрад (Exited (1)) дар лахзаи дакик кори cron кор мекунад docker system prune -a --volumes -f, Docker ҷилди номаълуми онро "истифоданашуда" мешуморад ва онҳоро ба таври доимӣ нест мекунад. Стрип --volumes аз ҳама скриптҳои тозакунӣ.
• ** Пайвасткунакҳои хоси пайвасткуниро истифода баред (/srv/prod_data/postgres:/var/lib/postgresql/data) ё пойгоҳи додаҳои берунии идорашаванда барои сарбории истеҳсолии давлатӣ**: Баръакси /var/lib/docker/volumes/, директорияҳои bind-mount дар берун /var/lib/docker/ ба ** харгиз даст намезананд docker compose down -v, docker volume rm, ё docker system prune --volumes.

Рақамҳои фавқулоддаи минтақавӣ ва протоколҳои агентӣ¶

Вақте ки як контейнер ё несткунии нигаҳдории Kubernetes ба амалиёти клиникии беморхона, фиристодани бехатарии ҷамъиятӣ ё маълумоти танзимшавандаи шахсӣ таъсир мерасонад, фавран афзоиш меёбад:

• Иёлоти Муттаҳида ва Канада: Рақам 911 агар нокомии кластери контейнер мониторинги клиникии бемор, системаҳои EHR ё фиристодани ҳолати фавқулоддаро ғайрифаъол созад. Дар бораи нест кардани инфрасохтори контейнерии зараровар ё ҳодисаҳои киберӣ ба CISA (1-844-Say-CISA / cisa.gov/report) ё Маркази Канада оид ба амнияти киберӣ (1-833-CYBER-88).
• ** Шоҳигарии Муттаҳида**: Рақам 999 барои таҳдид ба ҳаёт ё инфрасохтори муҳими NHS. Тибқи GDPR Бритониё, нобудсозии доимӣ ё аз даст додани дастрасии маълумоти шахсӣ бе нусхаи эҳтиётии барқароршаванда арзёбии огоҳиномаи вайронкунии 72-соатаро ба ICO (0303 123 1113).
• Иттиҳоди Аврупо: Рақам кунед 112 дар тамоми давлатхои аъзои ИА. Субъектҳое, ки тибқи Дастури NIS2, бояд ба CSIRT миллии худ дар давоми 24 соат пас аз қатъи шадиди хадамот огоҳии пешакӣ пешниҳод кунанд ва талафоти доимии маълумоти шахсӣ дар давоми 72 соат гузориш додани Моддаи 33-и GDPR-ро ба вуҷуд меорад.
• Австралия ва Зеландияи Нав: Рақам 000 дар Австралия ё 111 дар Зеландияи Нав; дар бораи ҳодисаҳои муҳими инфрасохтор ба ACSC гузориш диҳед (1300 CYBER1).
• Ҳиндустон ва Осиё-Уқёнуси Ором: Рақам 112 дар Ҳиндустон барои вокуниши фавқулодда; дар бораи ҳодисаҳои амнияти абрӣ ё контейнер ба CERT-In (incident@cert-in.org.in) дар доираи равзанаи 6-соатаи хатмй.

Саволҳои зуд-зуд додашаванда¶

мекунад docker compose down -v нест кардани пайвастҳои ҳост (./data:/var/lib/mysql) ё танҳо ҷилди Docker номдор ва беном?¶

`docker compose down -v` ТАНҲО ҷилдҳои номбаршударо нест мекунад, ки дар `volumes:` фасли `docker-compose.yml` ва ҷилдҳои беном, ки ба контейнер замима шудаанд; он ҳеҷ гоҳ файлҳоро дар дохили mount bind host нест мекунад (масалан `- /opt/mysql_data:/var/lib/mysql` ё `- ./postgres_data:/var/lib/postgresql/data`). Агар файли эҷоди шумо роҳи мизбонро, ки аз `/` ё `./`, он папкаи ҳостро худи ҳозир тафтиш кунед: файлҳои шумо то ҳол 100 фоиз солим мебошанд.

Чаро кард docker system prune --volumes Ҳаҷми пойгоҳи додаи маро нест кунед, вақте ки ман контейнерро танҳо барои 2 дақиқа барои навсозии тағирёбандаи муҳити зист боздоштам?¶

Бодиққат интизор шавед, ки фарқияти байни `docker stop` ва `docker rm`: агар контейнер танҳо бошад `Stopped / Exited` (дар `docker ps -a`), `docker system prune --volumes` мекунад не ҳаҷмҳои онро нест кунед, зеро контейнери қатъшуда то ҳол ба онҳо ишора мекунад. Аммо, агар шумо ran мезанед `docker rm ` (барои аз нав сохтани контейнер бо парчамҳои нав) ё агар шумо гузаштед `docker system prune -a --volumes` (ки он аввал ҳама контейнерҳои қатъшударо нест мекунад ва баъд ҳамаи ҷилдҳоеро, ки дигар ба ягон контейнер замима нашудаанд, нест мекунад), ҳаҷм пас аз миллисония хориҷ шудани контейнери боздошташуда "овезон" шуд ва фавран пас аз он пок карда шуд.

Оё ман метавонам ҳаҷми ҳазфшудаи Docker-ро дар дохили Docker Desktop дар Mac барқарор кунам (Apple Silicon / Intel) ё Windows (WSL2)?¶

Бале, агар шумо фавран Docker Desktop-ро тарк кунед, то мошини виртуалӣ корашро қатъ кунад `fstrim` бар зидди диски виртуалӣ. Дар macOS, Docker тамоми ҳаҷми Linux-ро дар дохили худ нигоҳ медорад `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; дар Windows WSL2, дар дохили `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. Инро нусхабардорӣ кунед `.raw` ё `.vhdx` фавран ба SSD-и беруна файлро насб кунед, онро дар Linux танҳо барои хондан замима кунед (бо истифода аз `losetup -Pr` барои `.raw` ё `qemu-nbd -r` барои `.vhdx`) ва давед `ext4magic` ё `PhotoRec` бар зидди виртуалӣ `ext4` тақсимот дар дохили.

Чӣ мешавад, агар ман бо Kubernetes StatefulSet тоза карда бошам kubectl delete statefulset postgres? Оё ин ҳам PVC-ҳои маро нест кард?¶

Не. Бо нобаёнӣ дар Kubernetes (агар `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` ба таври возеҳ дар Kubernetes 1.27+ конфигуратсия карда шуд), иҷро мешавад `kubectl delete statefulset` контролери StatefulSet ва Подҳои онро нест мекунад, тарк кардани ҳама `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) ва маълумоти асосии онҳо 100 фоиз бетаъхиранд. Танҳо аз нав муроҷиат кунед `StatefulSet` Манифести YAML бо ҳамон ном ва `volumeClaimTemplates`, ва Pods нав ба таври худкор аз нав ба мавҷуда замима мешавад `data-postgres-0` PVCs.

Чӣ тавр ман метавонам ба файлҳои дохили Docker дастрасӣ пайдо кунам overlay2 директория вақте ки контейнер оғоз карданро рад мекунад (CrashLoopBackOff / Exited (1))?¶

Контейнери харобшударо нест накунед. То он даме, ки контейнери қатъшуда дар он мавҷуд аст `docker ps -a`, қабати навишташавандаи он ва васлҳои ҳаҷм дар диск комилан солим мебошанд. Шумо метавонед файлҳоро мустақиман аз контейнери қатъшуда бо истифода аз нусхабардорӣ кунед `docker cp :/var/lib/postgresql/data /root/rescued_data`, ё мизбони дақиқи онро пайдо кунед `overlay2` роҳ тавассути давидан `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` ва хондани он директория бевосита ҳамчун `root`.

Чӣ мешавад, агар касе Kubernetes-ро нест кунад Namespace (kubectl delete ns prod) ва хамаи PVC-хо доштанд reclaimPolicy: Delete дар AWS EBS ё GCP?¶

Агар драйвери абрии CSI (`ebs.csi.aws.com` ё `pd.csi.storage.gke.io`) аллакай ичро карда шудааст `DeleteVolume` зеро `reclaimPolicy` буд `Delete`, се шабакаи бехатарии сатҳи абрро фавран санҷед: (1) ** AWS Bin барои Volumes EBS** -ро дар консоли AWS EC2 тафтиш кунед (агар қоидаи нигоҳдорӣ дар ҳисоб/тегҳо фаъол бошад, ҳаҷми ҳазфшудаи EBS дар қуттии партовҳо ҷойгир аст ва онро бо як клик барқарор кардан мумкин аст); (2) **Ҷадвалҳои аксбардории AWS Backup / DLM / GCP ** -ро барои акси садои охирини автоматӣ санҷед; ва (3) санҷед, ки оё махзани шумо WAL/binlogs ҷараён дорад (`WAL-G`, `pgBackRest`, `Litestream`) ба сатили S3/GCS.

Дастурҳои алоқаманд¶

• Диски сервер 100% пур (0 байт ройгон): пойгоҳи додаи WAL гузориш, вайроншудаи дарахти B ва барқарорсозии фазои сифр
• Тасодуфан rm -rf ё Shift+Delete дар Linux, macOS ё Windows: насби фаврӣ барои хондан ва кандакории inode
• Мошини виртуалии VMDK, VHDX ва qcow2 фасоди занҷири аксбардорӣ ва наҷотдиҳии гипервизор
• Супориши тасодуфии Git калидҳои AWS, файли .env ё калиди хусусии SSH ба репои оммавии GitHub
• Бӯҳрони хостинги веб, муҳоҷират ва барқарорсозии нусхабардорӣ
• Нусхаи эҳтиётии компютер, стратегияи 3-2-1 ва барқарорсозии офатҳои табиӣ
• Рақамҳои ёрии таъҷилӣ аз рӯи кишвар

Сарчашмаҳо ва роҳнамоии расмӣ¶

• Ҳуҷҷатҳои расмии Kubernetes (kubernetes.io / Фонди Cloud Native Computing): * Объекти нигоҳдорӣ дар ҳифзи истифода (kubernetes.io/pvc-protection Ниҳоятдиҳандагон), барқароркунии ҳаҷмҳои доимӣ (Retain против Delete), ва Амалиёт etcd Кластерҳо барои Kubernetes (etcdctl snapshot restore)*.
• Docker Inc. (docs.docker.com): * Идоракунии маълумот дар Docker: Ҳаҷмҳо, Пайвастшавӣ, overlay2 Архитектураи драйвери нигаҳдорӣ ва истинод ба Prune*.
• Ташкилоти ядрои Linux (kernel.org): Дар /proc Системаи файлӣ (procfs Барқарорсозии тасвири файлро тавассути /proc/<pid>/fd/) ва Ext4 Journal Specification.
• ext4magic Ҳуҷҷати лоиҳа (ext4magic.sourceforge.net): Барқарорсозии муомилоти судии Inode ва маҷалла дар системаҳои файлии Ext3/Ext4.
• Институти миллии стандартҳо ва технология (NIST) (Иёлоти Муттаҳида): Нашри махсуси 800-190: Дастури бехатарии контейнерҳо ва барқарорсозии ҳодисаҳо.