ዶከር ወይም ኩበርኔትስ የምርት መጠን ተሰርዟል፡ ማዳን docker system prune --volumes, overlay2 ኢኖድስ፣ እና etcd ቅጽበተ-ፎቶዎች¶

መሮጥ docker compose down -v, docker system prune -a --volumes, docker volume rm, ወይም kubectl delete pvc በምርት ውስጥ የተሳሳተ ተርሚናል ትር የቀጥታ PostgreSQL፣ MySQL፣ MariaDB፣ Redis፣ MongoDB ወይም SQLite የውሂብ ጎታ መጠንን ለማጽዳት በጣም ፈጣኑ መንገዶች አንዱ ነው። ወደ የ7-ቀን ሪሳይክል ቢን ከሚዘዋወሩ የክላውድ ቨርቹዋል ማሽን ቅጽበታዊ እይታዎች በተቃራኒ የዶከር የአካባቢ ድምጽ ሾፌር (/var/lib/docker/volumes/<name>/_data) እና ኩበርኔትስ local-path / hostPath አቅራቢዎች ወዲያውኑ መደበኛ POSIX ይሰጣሉ unlink() እና rmdir() በቀጥታ ከስር የሊኑክስ አስተናጋጅ ፋይል ስርዓት ጋር ይደውላል (ext4, XFS, ወይም Btrfs). ትዕዛዙ ከተጠናቀቀ በኋላ በዚያ ሊኑክስ አስተናጋጅ ላይ የሚከሰት እያንዳንዱ ጽሁፍ የተለቀቁትን የውሂብ ጎታ ብሎኮች በዲስክ ላይ መፃፍ ይችላል። የአገልጋይዎ ዲስክ 100 በመቶ ከሞላ (0 bytes free) አንድ ሰው ከመሮጡ በፊት docker system prune --volumes በድንጋጤ ተማከሩ የአገልጋይ ዲስክ 100% ሙሉ፣ የመረጃ ቋት WAL log bloat እና ዜሮ-ቦታ መልሶ ማግኛ; በባሬ-ሜታል ሊኑክስ ፋይል ከመያዣዎች ውጭ ስረዛዎች፣ ይመልከቱ ድንገተኛ rm -rf ወይም Shift-Delete በext4፣ XFS፣ APFS እና NTFS ላይ፡ ተነባቢ-ብቻ ዳግም መጫን እና የኢኖድ መቅረጽ እና ምናባዊ ማሽን VMDK፣ VHDX እና qcow2 ቅጽበታዊ ሰንሰለት ሙስና እና ሃይፐርቫይዘር ማዳን. ይህ የምርት መቋረጥ የሆስፒታል ታካሚ እንክብካቤ፣ የድንገተኛ አደጋ መላኪያ ወይም የህዝብ መገልገያ ደህንነት ስርዓቶች ላይ ተጽእኖ የሚፈጥር ከሆነ፣ የአካባቢዎን የድንገተኛ አደጋ ቁጥር ይደውሉ (911 በዩናይትድ ስቴትስ እና በካናዳ, 112 በመላው አውሮፓ ህብረት ፣ 999 በዩናይትድ ኪንግደም) ወይም የእኛን ማውጫ ይመልከቱ የአደጋ ጊዜ ቁጥሮች.

ይህንን አሁን ያድርጉ¶

1. ** አትሩጥ docker compose up -d, systemctl restart docker፣ ወይም የኩበርኔትስ ፖድ እንደገና መዘርጋት**፡ መያዣውን እንደገና መፍጠር ወይም Docker daemon እንደገና ማስጀመር ሜጋባይት አዲስ ይጽፋል overlay2 ሜታዳታ፣ መያዣ JSON ምዝግብ ማስታወሻዎች እና አዲስ የተጀመሩ ባዶ የውሂብ ጎታ ፋይሎች (initdb) በቀጥታ ከትክክለኛው በላይ ext4 ወይም XFS የተሰረዘ ድምጽህ ከሴኮንዶች በፊት ተቀምጦ የነበረበትን ብሎኮች።
2. ** የመያዣው ሂደት ከሆነ በ 5 ሰከንዶች ውስጥ ያረጋግጡ (postgres, mysqld, redis-server, node, python) አሁንም በማስታወስ ውስጥ እየሰራ ነው (ps aux እና sudo lsof +L1*** አንድ ሰው በተሰቀለው የድምጽ መጠን ውስጥ ፋይሎችን ከሰረዘ ወይም መያዣው ገና እየሰራ እያለ ማንነቱ ያልታወቀ ድምጽ ከጠፋ የሊኑክስ ከርነል 100 በመቶውን ያልተገናኙ የውሂብ ጎታ ፋይሎችን የመያዣው አስተናጋጅ ሂደት መታወቂያ እስከሆነ ድረስ በህይወት ይቆያልPID) ክፍት ፋይል ገላጭ ይይዛል (FD). እነዚያን ፋይሎች በቀጥታ ወደ ውጭ መቅዳት ይችላሉ። /proc/<PID>/fd/ ወይም /proc/<PID>/root/ መያዣው ከመቆሙ በፊት በዜሮ የውሂብ መጥፋት.
3. ** መያዣው ቀድሞውኑ ቆሞ ከሆነ እና ድምጹ ከተሰረዘ (docker compose down -v ወይም docker system prune --volumes), ፍሪዝ አስተናጋጅ ዲስክ ወዲያውኑ ይጽፋል ***: Docker daemon አቁም (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. ** ኩበርኔትስ ላይ ከሆኑ (kubectl delete pvc ወይም kubectl delete namespaceየቋሚ ድምጽን ያረጋግጡ (PV) ReclaimPolicy (kubectl get pv) ወድያው**፥
5. ከሆነ PV ነበረው። persistentVolumeReclaimPolicy: Retain, የእርስዎ ውሂብ ** አልተሰረዘም ***: የ PV በቀላሉ ወደ ተንቀሳቅሷል Released ሁኔታ እና የደመና ዲስክዎ (EBS, Azure Disk, Ceph RBD, NFS) 100 በመቶ አልተበላሸም።
6. ቢሆንም kubectl delete pvc ውስጥ ተጣብቋል Terminating, ኩበርኔትስ ** ፍጻሜዎች (kubernetes.io/pvc-protection*** ማንኛውም ፖድ አሁንም የ PVC ማጣቀሻ እስካልሆነ ድረስ የCSI ነጂውን የስር ማከማቻውን እንዳይሰርዝ ያግዱት። ውሂቡን ከሚሰራው Pod እስኪገለብጡ ድረስ ፖዱን አይሰርዙት።
7. ** ከስር ያለውን የማገጃ ክፍልፍል ምስልdd / ddrescue ከኤስኤስኤች በላይ) ከመሮጥዎ በፊት ወደ ውጫዊ ዲስክ ወይም የተለየ የደመና መጠን ext4magic, extundelete, ወይም PhotoRec** የውጤት ፋይሎችን የሚጽፉ የፋይል ጠራቢዎችን በፍፁም ወደ ሚመለሱበት የዲስክ ክፍልፍል አያሂዱ /var/lib/docker/volumes.
8. ** ለተበላሸ ወይም በአጋጣሚ ለተጠረገ የኩበርኔትስ ክላስተር ግዛት (kubectl delete crd / namespace), ማቆም kube-apiserver እና የቅርብ ጊዜዎን ወደነበሩበት ይመልሱ etcd ቅጽበታዊ ገጽ እይታ (etcdctl snapshot restore***: ክላስተር ከገባ etcd የስር የደመና ማከማቻ ጥራዞች ወደነበሩበት በመመለስ ላይ እያለ ተጠርጓል። etcd ሁሉንም ያገግማል PV, PVC, Secret, እና ConfigMap እቃዎች በአንድ ጊዜ.

የውሳኔ ዛፍ፡ የተሰረዘ የዶከር መጠን፣ overlay2 ንብርብር, ወይም Kubernetes PVC triage¶

የመያዣው ሂደት በህይወት እንዳለ፣ መጠኑ በአካባቢያዊ ዲስክ ወይም በደመና 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 --ጥራዞች)"| StopDocker["ወዲያውኑ አሂድ፡ sudo systemctl stop docker.socket docker በኮንቴይነር ተጭኗል"]

    WhichEnv -->|"ኩበርኔትስ፡ kubectl pvc/pv/statefulset/ስም ቦታን ሰርዝ"| K8sCheck{"ፖዱ አሁንም እየሰራ ነው ወይንስ PVC በማለቁ ላይ ተጣብቋል?"}

    K8sCheck -->|"አዎ፡ ፖድ አሁንም እየሰራ ነው (የፍፃሜ CSI መሰረዝን ማገድ)"| K8sExec["Pod አትሰርዝ -> kubectl exec / pg_dump / tar በ stdout ላይ ወደ አካባቢያዊ ዲስክ ወዲያውኑ ያሂዱ"]
    K8sCheck -->|"አይ፡ ፖድ ሄዷል -> kubectl ያግኙ pv"| ReclaimCheck{"የ PV ReclaimPolicy ምን ነበር?"}

    ReclaimCheck -->|"ማቆየት (የPV ሁኔታ = የተለቀቀ)"| ClearClaimRef["100% ውሂብ ያልተነካ -> PV አርትዕ spec.claimRef.uid -> ከአዲስ PVC ጋር እንደገና ማሰር"]
    ReclaimCheck -->|"ሰርዝ (Cloud EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"የክላውድ CSI ድምጽ ወይስ የአካባቢ አስተናጋጅ ዲስክ?"}

    CloudOrLocal -->|"Cloud CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["የክላውድ ኮንሶል ሪሳይክል ቢን / አውቶሜትድ የኢቢኤስ ቅጽበታዊ ገጽ እይታዎች / ሴፍ RBD መጣያ (rbd trash ls) ይመልከቱ"]
    CloudOrLocal -->|"የአካባቢ መስቀለኛ መንገድ ዲስክ (አካባቢያዊ ዱካ/አስተናጋጅ ዱካ)"| StopDocker

    StopDocker --> RemountRO["ዳግም ሰካ አስተናጋጅ ክፍልፍል ተነባቢ-ብቻ (mount-o remount,ro) ወይም ዥረት አግድ ምስል በኤስኤስኤች ላይ"]
    RemountRO --> HostFS{"ምን የፋይል ስርዓት ያስተናግዳል /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["ማረም / ext4magic ጆርናል Inode Transaction Rollback (-የጊዜ ማህተም) ተጠቀም"]
    HostFS -->|"XFS/Btrfs"| CarveRec["ለ SQLite፣ Postgres Heap ወይም InnoDB .ibd Btrfs Roots/xfs_irecover/ ብጁ ፊርማ ቀረጻ ይጠቀሙ።"]

ደረጃ 1፡ ዶከር እና ኩበርኔትስ በዲስክ ላይ ያለውን መጠን እንዴት እንደሚሰርዙ¶

ማንኛውንም የመልሶ ማግኛ ትእዛዝ ከማስኬድዎ በፊት መረጃዎ በሊኑክስ አስተናጋጅ ላይ የት እንደኖረ እና የመሰረዝ ትዕዛዙ ምን እንደነካ ይረዱ።

ደረጃ 2፡ ክፍት የውሂብ ጎታ ፋይሎችን አሁንም ከሚሰራ መያዣ ማዳን (/proc/<pid>/fd/)¶

ቆይ፡ ** መያዣው አሁን እየሰራ ነው?** በተደጋጋሚ፣ መሐንዲስ የመተግበሪያ ፍልሰት ስክሪፕትን፣ የጽዳት ክሮን ስራን ወይም መመሪያን ይሰራል rm -rf /var/lib/postgresql/data/* ወይም rm /app/data/production.sqlite3 በመሮጫ ኮንቴይነር ውስጥ፣ ወይም ከስር ያለውን የአስተናጋጅ ማሰሪያ-ማውንት አቃፊ ይሰርዛል /opt/app/data መያዣው ራሱ ሳለ (postgres, mysqld, mariadbd, redis-server, mongod, gunicorn, node) አሁንም እየሰራ ነው።

በሊኑክስ ውስጥ, መቼ ፋይል ከዲስክ አይሰረዝም rm ወይም unlink() ይባላል። ክፍት የፋይል ገላጭ እስከ መጨረሻው ሂደት ድረስ የእሱ የዲስክ ብሎኮች እና ኢንኖድ 100 በመቶ ተመድበው ሊነበቡ የሚችሉ ናቸውFD) ወደዚያ inode ይዘጋዋል ወይም ይወጣል.

ደረጃ 1 የአስተናጋጁን ሂደት መታወቂያ ያግኙ (PID) የእቃ መያዣው ሂደት¶

በሊኑክስ አስተናጋጅ መስቀለኛ መንገድ (በመያዣው ውስጥ ሳይሆን) አስተናጋጁን ያግኙ 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/በመጀመሪያ በዩኒክስ ሶኬት ወይም በ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፡ የተሰረዘ የዶከር ድምጽን በማገገም ላይ ext4 ወይም XFS መያዣው ከቆመ በኋላ¶

ብትሮጥስ? docker compose down -v ወይም docker system prune --volumes, ስለዚህ መያዣው ** አስቀድሞ ቆሟል ** እና ሁሉም /proc/<pid>/fd/ ገላጭዎች ተዘግተዋል? አሁን በሊኑክስ አስተናጋጅ ላይ ከጀርባ ዲስክ ጽሁፎች ጋር ውድድር ውስጥ ነዎት።

ደረጃ 1፡ የሊኑክስ አስተናጋጅ ፋይል ስርዓቱን በ10 ሰከንድ ውስጥ ያቀዘቅዙ¶

1. ** ዶከርን፣ ኮንቴይነርን፣ ኩቤሌትን እና ክሮን ወዲያውኑ ያቁሙ *** ስለዚህ ማንኛውም ኮንቴይነር፣ የጤና ምርመራ ወይም ሎግ ሮታተር ሌላ ባይት አይጽፍም /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. ** ክፋዩን ተነባቢ-ብቻ (ወይም ጥሬ ክፋይ ምስል በኤስኤስኤች ወደ ሌላ ማሽን ያሰራጩ)**:
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. ** በCloud VPS (AWS EC2, GCP, DigitalOcean, Hetzner, Linode) ላይ ከሆኑ: ወዲያውኑ ወደ የደመና ድር ኮንሶል ይሂዱ እና ** ቅጽበተ-ፎቶ ይፍጠሩ ** በአገልጋዩ የማገጃ ድምጽ ላይ (ወይም ጥሬውን የማገጃ መሳሪያውን በኤስኤስኤች ወደ ሁለተኛ አገልጋይ ያሰራጩ) 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፡ ግንኙነት የሌላቸውን የዶከር ጥራዝ ማውጫዎች በማገገም ላይ ext4 በመጠቀም ext4 ጆርናል (ext4magic እና debugfs)¶

መቼ docker volume rm ይሰርዛል /var/lib/docker/volumes/<vol_name>/_data በ ላይ ext4 የፋይል ስርዓት, ext4 ቀጥተኛ የማገጃ ጠቋሚዎችን ዜሮ ያደርጋል (i_block / ስፋት የዛፍ ሥር) በቀጥታ inode ሰንጠረዥ ውስጥ. ሆኖም ግን ext4 መጽሔት (ኢኖዴ <8>፣ በተለምዶ 128 MB ወደ 1024 MB ክብ የቀለበት ቋት) አሁንም ትክክለኛ የኢኖድ ሰንጠረዦች እና ማውጫ ብሎኮች ከትክክለኛው በፊት ታሪካዊ ቅጂዎችን ይይዛል። 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 ደቂቃ በፊት 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 ጆርናል አስቀድሞ በኢኖድ ጠቋሚዎች ላይ ተጠቅልሎ ፣ በጥሬው ዲስክ ምስል ላይ ፊርማ እና መዋቅርን ይጠቀሙ (docker_host_raw.img)::

1. ** ለ SQLite3 የውሂብ ጎታዎች (.sqlite, .db - ለምሳሌ፣ ቮልትዋርደን፣ Nextcloud፣ የቤት ረዳት፣ 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. ** ለ 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ቀጣይነት ያለው የድምፅ የይገባኛል ጥያቄን በድንገት መሰረዝ (kubectl delete pvc)፣ StatefulSet፣ ወይም አጠቃላይ የስም ቦታ (kubectl delete ns prod) ራሱን ከቻለ ዶከር የተለየ አርክቴክቸር ይከተላል።

ሁኔታ ሀ፡ የ PVC ትርኢቶች Terminating (The Finalizer Life Saver)¶

አሂድ፡

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

ሁኔታ ለ: PVC ተሰርዟል, እና kubectl get pv PersistentVolume inን ያሳያል Released ግዛት (ReclaimPolicy: Retain)¶

አሂድ፡

kubectl get pv

እንዴት ማድረግ እንደሚቻል Released ፒ.ቪ Available እንደገና በ10 ሰከንድ ውስጥ ከዜሮ የውሂብ መጥፋት ጋር፡- 1. የቋሚ ድምጽ ነገርን አርትዕ እና ሰርዝ spec.claimRef አግድ

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

ሁኔታ ሐ፡ የተጸዳ የኩበርኔትስ ክላስተር ሁኔታን ከኤን ወደነበረበት መመለስ etcd ቅጽበታዊ ገጽ እይታ (etcdctl snapshot restore)¶

አንድ ሰው ቢሮጥስ? kubectl delete namespace prod ወይም helm uninstall እና በራስ የሚተዳደር 200 የኩበርኔትስ መግለጫዎች፣ ሚስጥሮች፣ ኮንፊግ ካርታዎች እና የPV ትርጓሜዎችን አጠፋ። kubeadm, k3s, ወይም RKE2 መቆጣጠሪያ አውሮፕላን?

1. ** የቅርብ ጊዜዎን ያግኙ etcd ቅጽበተ-ፎቶ** (በነባሪ በ /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 ማከማቻ እና እያንዳንዱ የተሰረዘ የስም ቦታ፣ ሚስጥር፣ ኮንፊግማፕ እና ቋሚ የድምጽ ነገር እንደገና ይታያል።

ደረጃ 5፡ የዶከር እና የኩበርኔትስ ጥራዞች በአጋጣሚ እንዳይሰረዙ ማድረግ¶

አንዴ የምርት ዳታቤዝዎ ወደነበረበት ከተመለሰ፣ ነጠላ የCLI ትየባ በጭራሽ የቀጥታ ድምጽን መሰረዝ እንዳይችል እነዚህን አራት የሕንፃ ጥበቃ መንገዶችን ይተግብሩ።

• ** እያንዳንዱን ምርት Kubernetes ይቀይሩ StorageClass ከ reclaimPolicy: Delete ወደ reclaimPolicy: Retain** በነባሪ ፣ አብሮ የተሰራ የደመና ማከማቻ ክፍሎች (gp2, gp3, standard-rwo) ነባሪ ወደ reclaimPolicy: Delete, ማለትም PVC መሰረዝ የደመናውን ዲስክ ያጠፋል. ፍጠር ሀ StorageClass ጋር reclaimPolicy: Retain (ወይም ያሉትን ፒቪዎች በ kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') ስለዚህ የ PVC ወይም የስም ቦታን መሰረዝ ዋናውን የማገጃውን መጠን በጭራሽ አይሰርዘውም።
• AWS EBS Recycle Bin/GCP ቅጽበታዊ ዕቅዶችን አንቃ/Velero ከ CSI ቅጽበታዊ ገጽ እይታዎች ጋር፡ AWS EBS Recycle Binን ማንቃት የተሰረዘ የኢቢኤስ መጠን ከ7 እስከ 30 ቀናት ውስጥ የሲኤስአይ ሹፌር ቢደውልለትም ያቆያል። DeleteVolume.
• ** በጭራሽ አይጠቀሙ docker system prune --volumes በአውቶሜትድ ማጽጃ ስክሪፕቶች ወይም CI/CD ሯጮች**፡ የምርት ዳታቤዝ መያዣ ለአጭር ጊዜ ከተበላሸ (Exited (1)) በትክክለኛው ጊዜ የክሮን ሥራ ይሠራል docker system prune -a --volumes -f, ዶከር የማይታወቁ ጥራዞችን "ጥቅም ላይ ያልዋለ" ይቆጥረዋል እና እስከመጨረሻው ይሰርዛቸዋል. ማሰሪያ --volumes ከሁሉም የጽዳት ስክሪፕቶች.
• ** ግልጽ አስተናጋጅ ማሰሪያ ሰቀላዎችን ተጠቀም (/srv/prod_data/postgres:/var/lib/postgresql/data) ወይም በውጫዊ የሚተዳደሩ የውሂብ ጎታዎች ለግዛታዊ የምርት የሥራ ጫናዎች ***: በተለየ መልኩ /var/lib/docker/volumes/, ውጭ ማሰር-ማውንት ማውጫዎች ያስተናግዱ /var/lib/docker/ በፍፁም አልተነኩም docker compose down -v, docker volume rm, ወይም docker system prune --volumes.

የክልል የአደጋ ጊዜ ቁጥሮች እና የኤጀንሲ ፕሮቶኮሎች¶

የእቃ መያዢያ ወይም የኩበርኔትስ ማከማቻ ስረዛ የሆስፒታል ክሊኒካዊ ስራዎች፣ የህዝብ ደህንነት መላኪያ ወይም የተስተካከለ የግል መረጃ ላይ ተጽዕኖ በሚያሳድርበት ጊዜ ወዲያውኑ ይጨምራል፡

• ** ዩናይትድ ስቴትስ እና ካናዳ : ይደውሉ 911 የእቃ መያዣ ክላስተር ውድቀት ክሊኒካዊ የታካሚ ክትትልን፣ EHR ስርዓቶችን ወይም የአደጋ ጊዜ መላኪያን ካሰናከለ። ተንኮል አዘል ኮንቴይነር መሠረተ ልማት ማጽዳት ወይም የሳይበር አደጋዎችን ለ ** CISA ሪፖርት ያድርጉ (1-844-Say-CISA / cisa.gov/report ወይም ** የካናዳ የሳይበር ደህንነት ማዕከል (1-833-CYBER-88)**።
• ** ዩናይትድ ኪንግደም ***: ይደውሉ 999 ለሕይወት አስጊዎች ወይም ወሳኝ የኤንኤችኤስ መሠረተ ልማት። በዩኬ GDPR ስር ያለ ምትኬ ያለ የግል መረጃ ለዘለቄታው መጥፋት ወይም መጥፋት የ72 ሰአታት ጥሰት ማሳወቂያ ለ ICO (መገምገም) ይጠይቃል (0303 123 1113)።
• ** የአውሮፓ ህብረት ***: ይደውሉ 112 በሁሉም የአውሮፓ ህብረት አባል ሀገራት። በ NIS2 መመሪያ ስር ያሉ አካላት ከባድ የአገልግሎት መቋረጥ በደረሰባቸው 24 ሰአት ውስጥ የቅድመ ማስጠንቀቂያ ለሀገራቸው CSIRT ማቅረብ አለባቸው እና ቋሚ የግል መረጃ መጥፋት ቀስቃሾች የጂዲፒአር አንቀጽ 33 ሪፖርት በ72 ሰአታት ውስጥ።
• አውስትራሊያ እና ኒውዚላንድ፡ ይደውሉ 000 በአውስትራሊያ ወይም 111 በኒው ዚላንድ; ወሳኝ የመሠረተ ልማት ጉዳዮችን ለ ACSC ሪፖርት አድርግ1300 CYBER1)።
• ህንድ እና እስያ-ፓሲፊክ፡ ደውል 112 ለድንገተኛ ምላሽ በህንድ ውስጥ; የደመና ወይም የመያዣ ደህንነት አደጋዎችን ለ ** CERT-In (incident@cert-in.org.in*** አስገዳጅ በሆነው የ6-ሰዓት መስኮት ውስጥ።

በተደጋጋሚ የሚጠየቁ ጥያቄዎች¶

ያደርጋል docker compose down -v የአስተናጋጅ ማሰሪያ ሰቀላዎችን ሰርዝ (./data:/var/lib/mysql) ወይስ የተሰየሙ እና የማይታወቁ የዶከር ጥራዞች ብቻ?¶

`docker compose down -v` በ ውስጥ የተገለጹትን የተሰየሙ ጥራዞች ብቻ ይሰርዛል `volumes:` ክፍል የ `docker-compose.yml` እና ስም-አልባ ጥራዞች ከእቃ መያዣዎች ጋር ተያይዘዋል; ነው። በፍጹም በአስተናጋጅ ማሰሪያ ውስጥ ያሉ ፋይሎችን ይሰርዛል (እንደ `- /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` ያደርጋል አይደለም የቆመው መያዣ አሁንም እነሱን ስለሚጠቅስ ድምጾቹን ሰርዝ። ቢሆንም፣ ከሮጥክ `docker rm ` (መያዣውን በአዲስ ባንዲራዎች እንደገና ለመፍጠር) ወይም ካለፉ `docker system prune -a --volumes` (ይህም በመጀመሪያ ሁሉንም የቆሙ መያዣዎችን ይሰርዛል እና ከዚያም ሁሉንም ጥራዞች ከአሁን በኋላ በማናቸውም ኮንቴይነሮች ላይ ያልተያያዙትን ይሰርዛል)፣ ድምጹ "አስደንጋጭ" ሆነ የቆመው ኮንቴይነር በሚሊሰከንድ ጊዜ ተወግዶ ወዲያው ተጠርጓል።

የተሰረዘ የዶከር መጠን በ Docker Desktop ውስጥ በ Mac ላይ መልሶ ማግኘት እችላለሁን (Apple Silicon / Intel) ወይም ዊንዶውስ (WSL2)?¶

አዎ፣ ወዲያውኑ የዶክተር ዴስክቶፕን ካቆሙ ቨርቹዋል ማሽኑ መስራቱን ያቆማል `fstrim` በምናባዊ ዲስክ ላይ። በ macOS ላይ Docker ሁሉንም የሊኑክስ መጠኖች በውስጡ ያከማቻል `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; በዊንዶውስ WSL2 ፣ ውስጥ `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. ያንን ይቅዱ `.raw` ወይም `.vhdx` ወዲያውኑ ወደ ውጫዊ SSD ፋይል ያድርጉ፣ በሊኑክስ ተነባቢ-ብቻ ያያይዙት (በመጠቀም `losetup -Pr` ለ `.raw` ወይም `qemu-nbd -r` ለ `.vhdx`) እና ሩጡ `ext4magic` ወይም `PhotoRec` ምናባዊውን በመቃወም `ext4` ውስጥ ክፍፍል.

የ Kubernetes StatefulSet ን ብሰርዝስ kubectl delete statefulset postgres? ያ የእኔን PVCs ሰርዞ ይሆን?¶

አይ. በነባሪ በ Kubernetes (ከቀር `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` በ Kubernetes 1.27+ ላይ በግልፅ ተዋቅሯል)፣ እየሮጠ ነው። `kubectl delete statefulset` የStatefulSet መቆጣጠሪያውን እና ፖዶቹን ይሰርዛል፣ ሁሉንም ትቶ `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) እና ከስር ያለው መረጃ 100 በመቶ ሳይበላሽ ነው።. በቀላሉ እንደገና ያመልክቱ `StatefulSet` YAML በተመሳሳዩ ስም እና `volumeClaimTemplates`, እና አዲሱ ፖድስ በራስ-ሰር ከነባሩ ጋር እንደገና ይያያዛል `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 ሪሳይክል ቢን ለኢቢኤስ ጥራዞች** በAWS EC2 ኮንሶል ውስጥ ያረጋግጡ (የማቆየት ህግ በመለያው/መለያዎች ላይ ንቁ ከሆነ፣ የተሰረዘው የኢቢኤስ መጠን በሪሳይክል ቢን ውስጥ ተቀምጦ በ1 ጠቅታ ወደነበረበት መመለስ ይቻላል)። (2) **AWS ምትኬ/ዲኤልኤም/ጂሲፒ ቅጽበተ ፎቶ መርሐግብሮችን** በጣም የቅርብ ጊዜ አውቶማቲክ በሆነ ቅጽበታዊ ገጽ እይታ ላይ ያረጋግጡ። እና (3) የውሂብ ጎታዎ WAL/binlogs እየተለቀቀ መሆኑን ያረጋግጡ (`WAL-G`, `pgBackRest`, `Litestream`) ወደ S3/GCS ባልዲ።

ተዛማጅ መመሪያዎች¶

• የአገልጋይ ዲስክ 100% ሙሉ (0 ባይት ነፃ)፡ ዳታቤዝ WAL log bloat፣ የተበላሸ ቢ-ዛፍ እና ዜሮ-ክፍተት መልሶ ማግኘት
• ድንገተኛ rm -rf ወይም Shift+ Delete በሊኑክስ፣ ማክኦኤስ ወይም ዊንዶውስ ላይ፡ ወዲያውኑ ተነባቢ-ብቻ ዳግም ሰካ እና የኢኖድ መቅረጽ
• ምናባዊ ማሽን VMDK፣ VHDX እና qcow2 ቅጽበታዊ ሰንሰለት ሙስና እና ሃይፐርቫይዘር ማዳን
• ድንገተኛ Git የAWS ቁልፎችን፣ .env ፋይልን ወይም የግል ኤስኤስኤች ቁልፍ ለህዝብ GitHub ሪፖ
• የድር ማስተናገጃ ቀውስ፣ ፍልሰት እና ምትኬ ወደነበረበት መመለስ
• የኮምፒውተር ምትኬዎች፣ የ3-2-1 ስትራቴጂ እና የአደጋ ማገገም
• የአደጋ ጊዜ ቁጥሮች በአገር

ምንጮች እና ኦፊሴላዊ መመሪያ¶

• የኩበርኔትስ ኦፊሴላዊ ሰነድ (kubernetes.io / Cloud Native Computing Foundation)፡ የማከማቻ ነገር በአጠቃቀም ጥበቃ ላይ (kubernetes.io/pvc-protection ማጠናቀቂያዎች)፣ ቀጣይነት ያላቸውን ጥራዞች መልሶ ማግኘት (Retain vs. Delete) እና ኦፕሬቲንግ etcd ስብስቦች ለ Kubernetes (etcdctl snapshot restore)።
• ዶከር ኢንክ.docs.docker.com): * በ Docker ውስጥ ውሂብን ያስተዳድሩ: ጥራዞች, ማሰሪያዎች, overlay2 የማከማቻ ሹፌር አርክቴክቸር፣ እና Prune ማጣቀሻ*።
• የሊኑክስ ኮርነል ድርጅት (እ.ኤ.አ.)kernel.org): * የ /proc የፋይል ስርዓት (procfs የፋይል ገላጭ መልሶ ማግኛን በ በኩል ይክፈቱ /proc/<pid>/fd/) እና Ext4 ጆርናል ዝርዝር *.
• ext4magic የፕሮጀክት ሰነድ (ext4magic.sourceforge.net): የፎረንሲክ ኢኖድ እና ጆርናል ግብይት ማግኛ በExt3/Ext4 የፋይል ሲስተሞች።
• ብሔራዊ ደረጃዎች እና ቴክኖሎጂ ኢንስቲትዩት (እ.ኤ.አ.)NIST) (ዩናይትድ ስቴትስ): ልዩ ሕትመት 800-190: የመተግበሪያ ኮንቴይነር ደህንነት መመሪያ እና የአደጋ ማገገሚያ.