Skip to content

ഡോക്കർ അല്ലെങ്കിൽ കുബർനെറ്റസ് പ്രൊഡക്ഷൻ വോളിയം ഇല്ലാതാക്കി: രക്ഷാപ്രവർത്തനം docker system prune --volumes, overlay2 ഇനോഡുകൾ, ഒപ്പം etcd സ്നാപ്പ്ഷോട്ടുകൾ

രാജ്യത്തിനനുസരിച്ച് എമർജൻസി നമ്പറുകൾ വ്യത്യസ്തമാണ്. ഈ പേജ് 911 ഉപയോഗിക്കുന്നു, യുണൈറ്റഡ് സ്റ്റേറ്റ്സിനും കാനഡയ്ക്കുമുള്ള നമ്പർ. മറ്റ് പല രാജ്യങ്ങളും 112, 999 അല്ലെങ്കിൽ മറ്റൊരു നമ്പർ ഉപയോഗിക്കുന്നു. നിങ്ങളുടെ രാജ്യത്തിനായുള്ള നമ്പർ കണ്ടെത്തുക.

ഓടുന്നു 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 ലോഗ് ബ്ലോട്ട്, സീറോ-സ്പേസ് വീണ്ടെടുക്കൽ; കണ്ടെയ്നറുകൾക്ക് പുറത്ത് ബെയർ-മെറ്റൽ ലിനക്സ് ഫയൽ ഇല്ലാതാക്കുന്നതിന്, കാണുക ext4, XFS, APFS, NTFS എന്നിവയിൽ ആകസ്മികമായ rm -rf അല്ലെങ്കിൽ Shift-Delete: റീഡ്-ഒൺലി റീമൗണ്ടും ഐനോഡ് കൊത്തുപണിയും ഒപ്പം വെർച്വൽ മെഷീൻ VMDK, VHDX, qcow2 സ്നാപ്പ്ഷോട്ട് ചെയിൻ അഴിമതിയും ഹൈപ്പർവൈസർ റെസ്ക്യൂവും. ഈ ഉൽപ്പാദന തടസ്സം ആശുപത്രിയിലെ രോഗി പരിചരണം, എമർജൻസി ഡിസ്പാച്ച് അല്ലെങ്കിൽ പൊതു ഉപയോഗ സുരക്ഷാ സംവിധാനങ്ങളെ ബാധിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ പ്രാദേശിക എമർജൻസി നമ്പറിൽ വിളിക്കുക (911 അമേരിക്കയിലും കാനഡയിലും, 112 യൂറോപ്യൻ യൂണിയനിലുടനീളം, 999 യുണൈറ്റഡ് കിംഗ്ഡത്തിൽ) അല്ലെങ്കിൽ ഞങ്ങളുടെ ഡയറക്ടറി പരിശോധിക്കുക അടിയന്തര നമ്പറുകൾ.

ഇപ്പോൾ ഇത് ചെയ്യുക

  1. ** ഓടരുത് docker compose up -d, systemctl restart docker, അല്ലെങ്കിൽ കുബർനെറ്റസ് പോഡ് വീണ്ടും വിന്യസിക്കുക**: കണ്ടെയ്‌നർ പുനഃസൃഷ്‌ടിക്കുകയോ ഡോക്കർ ഡെമൺ പുനരാരംഭിക്കുകയോ ചെയ്യുന്നത് മെഗാബൈറ്റുകൾ പുതിയതായി എഴുതുന്നു overlay2 മെറ്റാഡാറ്റ, കണ്ടെയ്നർ JSON ലോഗുകൾ, പുതുതായി ആരംഭിച്ച ശൂന്യമായ ഡാറ്റാബേസ് ഫയലുകൾ (initdb) കൃത്യമായും നേരിട്ട് ext4 അല്ലെങ്കിൽ XFS നിങ്ങളുടെ ഇല്ലാതാക്കിയ വോളിയം സെക്കൻ്റുകൾക്ക് മുമ്പ് ഉണ്ടായിരുന്ന ബ്ലോക്കുകൾ.
  2. ** കണ്ടെയ്നർ പ്രോസസ്സ് ആണെങ്കിൽ 5 സെക്കൻഡിനുള്ളിൽ പരിശോധിക്കുക (postgres, mysqld, redis-server, node, python) ഇപ്പോഴും മെമ്മറിയിൽ പ്രവർത്തിക്കുന്നു (ps aux ഒപ്പം sudo lsof +L1): ആരെങ്കിലും മൗണ്ട് ചെയ്‌ത വോള്യത്തിനുള്ളിൽ ഫയലുകൾ ഇല്ലാതാക്കുകയോ അല്ലെങ്കിൽ കണ്ടെയ്‌നർ പ്രവർത്തിക്കുമ്പോൾ അജ്ഞാത വോളിയം അൺലിങ്ക് ചെയ്യുകയോ ചെയ്‌താൽ, Linux കേർണൽ ലിങ്ക് ചെയ്യാത്ത ഡാറ്റാബേസ് ഫയലുകളുടെ 100 ശതമാനം ഡിസ്‌കിൽ സജീവമായി സൂക്ഷിക്കുന്നു കണ്ടെയ്‌നറിൻ്റെ ഹോസ്റ്റ് പ്രോസസ്സ് ഐഡി (PID) ഒരു തുറന്ന ഫയൽ ഡിസ്ക്രിപ്റ്റർ കൈവശം വയ്ക്കുന്നു (FD). നിങ്ങൾക്ക് ആ ഫയലുകൾ നേരിട്ട് പകർത്താനാകും /proc/<PID>/fd/ അല്ലെങ്കിൽ /proc/<PID>/root/ കണ്ടെയ്നർ നിർത്തുന്നതിന് മുമ്പ് ഡാറ്റ നഷ്ടം പൂജ്യത്തോടെ.
  3. ** കണ്ടെയ്‌നർ ഇതിനകം നിർത്തുകയും വോളിയം ഇല്ലാതാക്കുകയും ചെയ്‌തിട്ടുണ്ടെങ്കിൽ (docker compose down -v അല്ലെങ്കിൽ docker system prune --volumes), ഫ്രീസ് ഹോസ്റ്റ് ഡിസ്ക് ഉടൻ എഴുതുന്നു**: ഡോക്കർ ഡെമൺ നിർത്തുക (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, നിങ്ങളുടെ ഡാറ്റ ** ഇല്ലാതാക്കിയിട്ടില്ല**: the PV ലളിതമായി നീക്കി Released സ്റ്റാറ്റസും നിങ്ങളുടെ ക്ലൗഡ് ഡിസ്കും (EBS, Azure Disk, Ceph RBD, NFS) 100 ശതമാനം കേടുകൂടാതെയിരിക്കുന്നു.
  6. എങ്കിൽ പോലും kubectl delete pvc കുടുങ്ങിയിരിക്കുന്നു Terminating, കുബർനെറ്റസ് ഫൈനലൈസറുകൾ (kubernetes.io/pvc-protection) ഏതെങ്കിലും പോഡ് ഇപ്പോഴും പിവിസിയെ പരാമർശിക്കുന്നിടത്തോളം, അടിസ്ഥാന സംഭരണം ഇല്ലാതാക്കുന്നതിൽ നിന്ന് 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 ഒരേസമയം വസ്തുക്കൾ.

Danger

** ഒരിക്കലും നീക്കം ചെയ്യരുത് kubernetes.io/pvc-protection അല്ലെങ്കിൽ kubernetes.io/pv-protection കൂടെ ഫൈനലൈസർ kubectl patch ... -p '{"metadata":{"finalizers":null}}' ഒരു പിവിസി കുടുങ്ങിയപ്പോൾ Terminating**: നിങ്ങളുടെ ക്ലൗഡ് സിഎസ്ഐ ഡ്രൈവറെ നിലനിർത്തുന്നത് ആ ഫൈനലൈസർ മാത്രമാണ് (aws-ebs-csi-driver, pd.csi.storage.gke.io, Longhorn, Rook-Ceph) ഒരു ഹാർഡ്‌വെയർ ഇഷ്യൂ ചെയ്യുന്നതിൽ നിന്ന് DeleteVolume നിങ്ങളുടെ പ്രൊഡക്ഷൻ ഡിസ്ക് നശിപ്പിക്കാൻ API കോൾ. പിവിസി കുടുങ്ങിക്കിടക്കുമ്പോൾ Terminating, പോഡ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു, വോളിയം ഇപ്പോഴും മൗണ്ട് ചെയ്തിരിക്കുന്നു: റൺ kubectl exec അല്ലെങ്കിൽ kubectl cp (അല്ലെങ്കിൽ pg_dump / mysqldump) പോഡ് അവസാനിക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ ഡാറ്റാബേസിൻ്റെ 100 ശതമാനവും രക്ഷപ്പെടുത്താൻ ഉടൻ.

ഡിസിഷൻ ട്രീ: ഡോക്കർ വോളിയം ഇല്ലാതാക്കി, overlay2 പാളി, അല്ലെങ്കിൽ കുബർനെറ്റസ് പിവിസി ട്രയേജ്

കണ്ടെയ്‌നർ പ്രോസസ്സ് ഇപ്പോഴും സജീവമാണോ, വോളിയം ലോക്കൽ ഡിസ്‌ക് അല്ലെങ്കിൽ ക്ലൗഡ് സിഎസ്ഐ സ്‌റ്റോറേജ് പിന്തുണച്ചതാണോ, ഏത് ഫയൽസിസ്റ്റം ഹോസ്‌റ്റാണ് എന്നതിനെ അടിസ്ഥാനമാക്കി വേഗതയേറിയ സീറോ-ലോസ് വീണ്ടെടുക്കൽ പാത തിരഞ്ഞെടുക്കാൻ ഈ ഫ്ലോചാർട്ട് ഉപയോഗിക്കുക. /var/lib/docker:

flowchart TD
    Start["ഡോക്കർ അല്ലെങ്കിൽ കുബർനെറ്റസ് കമാൻഡ് ഇല്ലാതാക്കിയതിന് ശേഷം പ്രൊഡക്ഷൻ ഡാറ്റ നഷ്‌ടമായി"] --> WhichEnv{"ഏത് പ്ലാറ്റ്‌ഫോമും കമാൻഡുമാണ് നഷ്ടത്തിന് കാരണമായത്?"}

    WhichEnv -->|"ഡോക്കർ: കണ്ടെയ്‌നർ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു (വോളിയം/കണ്ടെയ്‌നറിനുള്ളിൽ ഫയലുകൾ അൺലിങ്ക് ചെയ്‌തിരിക്കുന്നു)"| ProcRescue["sudo lsof +L1, /proc/PID/fd/N അല്ലെങ്കിൽ /proc/PID/root/ വഴി അൺലിങ്ക് ചെയ്യാത്ത ഫയൽ വിവരണങ്ങൾ തുറക്കുക"]

    WhichEnv -->|"ഡോക്കർ: കണ്ടെയ്നർ നിർത്തി, വോളിയം ഇല്ലാതാക്കി (കംപോസ് ഡൌൺ -വി / പ്രൂൺ --വോളിയം)"| StopDocker["ഉടൻ പ്രവർത്തിപ്പിക്കുക: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"കുബെർനെറ്റസ്: kubectl പിവിസി / പിവി / സ്റ്റേറ്റ്ഫുൾസെറ്റ് / നെയിംസ്പേസ് ഇല്ലാതാക്കുക"| K8sCheck{"പോഡ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടോ അല്ലെങ്കിൽ പിവിസി അവസാനിപ്പിക്കുന്നതിൽ കുടുങ്ങിയിട്ടുണ്ടോ?"}

    K8sCheck -->|"അതെ: പോഡ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു (ഫൈനലൈസർ CSI ഇല്ലാതാക്കുന്നത് തടയുന്നു)"| K8sExec["പോഡ് ഇല്ലാതാക്കരുത് -> kubectl exec / pg_dump / tar stdout വഴി ലോക്കൽ ഡിസ്കിലേക്ക് ഉടൻ പ്രവർത്തിപ്പിക്കുക"]
    K8sCheck -->|"നമ്പർ: പോഡ് ഗോൺ -> ചെക്ക് kubectl get pv"| ReclaimCheck{"എന്തായിരുന്നു പിവി വീണ്ടെടുക്കൽ നയം?"}

    ReclaimCheck -->|"നിലനിർത്തുക (PV സ്റ്റാറ്റസ് = റിലീസ്)"| ClearClaimRef["100% ഡാറ്റ കേടുകൂടാതെ -> spec.claimRef.uid നീക്കം ചെയ്യാൻ PV എഡിറ്റ് ചെയ്യുക -> പുതിയ PVC-ലേക്ക് വീണ്ടും ബൈൻഡ് ചെയ്യുക"]
    ReclaimCheck -->|"ഇല്ലാതാക്കുക (ക്ലൗഡ് EBS / PD / Longhorn / ലോക്കൽ-പാത്ത്)"| CloudOrLocal{"ക്ലൗഡ് CSI വോളിയം അല്ലെങ്കിൽ ലോക്കൽ ഹോസ്റ്റ് ഡിസ്ക്?"}

    CloudOrLocal -->|"ക്ലൗഡ് CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["ക്ലൗഡ് കൺസോൾ റീസൈക്കിൾ ബിൻ / ഓട്ടോമേറ്റഡ് ഇബിഎസ് സ്നാപ്പ്ഷോട്ടുകൾ / സെഫ് ആർബിഡി ട്രാഷ് (rbd ട്രാഷ് ls) പരിശോധിക്കുക"]
    CloudOrLocal -->|"ലോക്കൽ നോഡ് ഡിസ്ക് (ലോക്കൽ-പാത്ത് / ഹോസ്റ്റ്പാത്ത്)"| StopDocker

    StopDocker --> RemountRO["റീമൗണ്ട് ഹോസ്റ്റ് പാർട്ടീഷൻ റീഡ്-ഒൺലി (മൌണ്ട് -ഒ റീമൗണ്ട്,റോ) അല്ലെങ്കിൽ എസ്എസ്എച്ച് വഴി ചിത്രം ബ്ലോക്ക് ചെയ്യുക"]
    RemountRO --> HostFS{"ഏത് ഫയൽസിസ്റ്റം ഹോസ്റ്റുകളാണ് /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["debugfs / ext4magic ജേണൽ ഇനോഡ് ട്രാൻസാക്ഷൻ റോൾബാക്ക് ഉപയോഗിക്കുക (-ഒരു ടൈംസ്റ്റാമ്പ്)"]
    HostFS -->|"XFS / Btrfs"| CarveRec["SQLite, Postgres Heap അല്ലെങ്കിൽ InnoDB .ibd എന്നിവയ്‌ക്കായി Btrfs റൂട്ടുകൾ / xfs_irecover / കസ്റ്റം സിഗ്നേച്ചർ കാർവിംഗ് ഉപയോഗിക്കുക"]

ഘട്ടം 1: എങ്ങനെയാണ് ഡോക്കറും കുബർനെറ്റും ഡിസ്കിലെ വോള്യങ്ങൾ ഇല്ലാതാക്കുന്നത്

ഏതെങ്കിലും വീണ്ടെടുക്കൽ കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ്, Linux ഹോസ്റ്റിൽ നിങ്ങളുടെ ഡാറ്റ ഭൗതികമായി എവിടെയാണ് ജീവിച്ചിരിക്കുന്നതെന്നും ഡിലീറ്റ് കമാൻഡ് യഥാർത്ഥത്തിൽ സ്പർശിച്ചതെന്താണെന്നും മനസ്സിലാക്കുക:

സ്റ്റോറേജ് തരം & കമാൻഡ് ഇല്ലാതാക്കുക ലിനക്സ് നോഡിൽ ഹോസ്റ്റ് ഫയൽസിസ്റ്റം പാത്ത് ഡിലീറ്റ് കമാൻഡ് യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്തത് ഉടനടി വീണ്ടെടുക്കൽ രീതി
പേരുള്ള ഡോക്കർ വോളിയം (docker volume rm അല്ലെങ്കിൽ docker compose down -v) /var/lib/docker/volumes/<vol_name>/_data ഉള്ളിലെ ഫയലുകൾ അൺലിങ്ക് ചെയ്തു _data/ എന്നതിൽ നിന്നുള്ള ഡയറക്‌ടറി എൻട്രി നീക്കം ചെയ്‌തു /var/lib/docker/volumes/metadata.db (boltdb). ഡോക്കർ ഉടൻ നിർത്തുക, റീമൗണ്ട് ചെയ്യുക /var/lib/docker വായിക്കാൻ മാത്രം, കൂടാതെ ലിങ്ക് ചെയ്യാത്ത ഐനോഡുകൾ വീണ്ടെടുക്കുക ext4magic / debugfs അല്ലെങ്കിൽ ഒപ്പ് കൊത്തുപണി.
** അജ്ഞാത ഡോക്കർ വോളിയം (docker run -v /var/lib/mysql + docker rm -v അല്ലെങ്കിൽ docker system prune --volumes)** /var/lib/docker/volumes/<64-char-hex-id>/_data docker system prune --volumes നിലവിലുള്ള ഒരു കണ്ടെയ്‌നറെങ്കിലും നിലവിൽ പരാമർശിക്കാത്ത എല്ലാ അജ്ഞാതവും പേരുള്ളതുമായ വോളിയം ഇല്ലാതാക്കുന്നു. ഡോക്കർ ഉടൻ നിർത്തുക; നിങ്ങൾക്ക് മറ്റ് നിർത്തിയ കണ്ടെയ്‌നറുകൾ ഉണ്ടെങ്കിൽ, അവയുടെ വോള്യം പ്രൂൺ ചെയ്യപ്പെടാത്തത്, ബാക്കിയുള്ളവ പരിശോധിക്കുക /var/lib/docker/volumes/*/_data അനുവദിക്കാത്ത ബ്ലോക്കുകൾ കൊത്തിയെടുക്കുന്നതിന് മുമ്പ് ആദ്യം ഫോൾഡറുകൾ.
** കണ്ടെയ്നർ റൈറ്റബിൾ ലെയർ (docker rm <container> ഒരു വോളിയത്തിന് പുറത്ത് ഡാറ്റ എഴുതിയപ്പോൾ)** /var/lib/docker/overlay2/<layer-id>/diff/ കണ്ടെയ്‌നറിൻ്റെ മുകൾഭാഗം അൺലിങ്ക് ചെയ്‌തു diff/ അകത്തുള്ള ഡയറക്ടറി overlay2 സ്റ്റോറേജ് ഡ്രൈവർ. ഡോക്കർ ഉടനടി നിർത്തി ലിങ്ക് ചെയ്യാത്ത ഡയറക്ടറി ട്രീ വീണ്ടെടുക്കുക ext4 ജേണൽ അല്ലെങ്കിൽ XFS ബ്ലോക്കുകൾ.
** MacOS അല്ലെങ്കിൽ Windows-ലെ ഡോക്കർ ഡെസ്ക്ടോപ്പ് (docker system prune --volumes)** ഒരൊറ്റ വെർച്വൽ മെഷീൻ ഡിസ്ക് ഇമേജിനുള്ളിൽ: -/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw (macOS) അല്ലെങ്കിൽ %LocalAppData%\Docker\wsl\disk\docker_data.vhdx (Windows WSL2). അയച്ചു unlink() Linux VM-നുള്ളിൽ, എങ്കിൽ discard/TRIM സജീവമാണ് Docker.raw / docker_data.vhdx, ഹോസ്റ്റ് ഫയലിൽ വിരളമായ ദ്വാരങ്ങൾ പഞ്ച് ചെയ്തു. 5 സെക്കൻഡിനുള്ളിൽ ഡോക്കർ ഡെസ്ക്ടോപ്പിൽ നിന്ന് പുറത്തുകടക്കുക, പകർത്തുക Docker.raw അല്ലെങ്കിൽ docker_data.vhdx ഒരു ബാഹ്യ ഡ്രൈവിലേക്ക്, പ്രവർത്തിപ്പിക്കുക ext4magic / PhotoRec വെർച്വൽ ഡിസ്ക് ഇമേജിനെതിരെ.
** കുബെർനെറ്റസ് പിവിസി Delete Cef RBD-യിലെ വീണ്ടെടുക്കൽ നയം (Rook-Ceph) അല്ലെങ്കിൽ ലോംഗ്ഹോൺ** Ceph OSD പൂൾ (rbd) അല്ലെങ്കിൽ /var/lib/longhorn/replicas/. എങ്കിൽ csi-rbdplugin ഉണ്ട് trash പ്രവർത്തനക്ഷമമാക്കി (rbd trash), RBD ചിത്രം Ceph ട്രാഷ് ബിന്നിലേക്ക് നീക്കി; അല്ലെങ്കിൽ ബ്ലോക്കുകൾ മാപ്പ് ചെയ്യാത്തതാണ്. ഓടുക rbd trash ls --pool <pool> ഉള്ളിൽ rook-ceph-tools ഉപയോഗിച്ച് പുനഃസ്ഥാപിക്കുക rbd trash restore.

ഘട്ടം 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) ഇപ്പോഴും പ്രവർത്തിക്കുന്നു.

Linux-ൽ, ഒരു ഫയൽ ഡിസ്കിൽ നിന്ന് നീക്കം ചെയ്യപ്പെടില്ല rm അല്ലെങ്കിൽ unlink() വിളിക്കുന്നു. അതിൻ്റെ ഡിസ്‌ക് ബ്ലോക്കുകളും ഐനോഡും 100 ശതമാനം അലോക്കേറ്റ് ചെയ്‌തിരിക്കുന്നതും വായിക്കാൻ കഴിയുന്നതും ഒരു ഓപ്പൺ ഫയൽ ഡിസ്‌ക്രിപ്‌റ്റർ കൈവശം വയ്ക്കുന്നത് വരെ (FD) ആ ഐനോഡ് അത് അടയ്ക്കുകയോ പുറത്തുകടക്കുകയോ ചെയ്യുന്നു.

ഘട്ടം 1: ഹോസ്റ്റ് പ്രോസസ്സ് ഐഡി കണ്ടെത്തുക (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)
കോളം നോക്കൂ NLINK: അത് പറയുന്നു 0, ഫയലിൻ്റെ പേര് അവസാനിക്കുന്നത് (deleted). ഫയൽ പൂർണ്ണമായും അപ്രത്യക്ഷമായി ls /var/lib/docker/volumes/..., എന്നിട്ടും ** ഓരോ ബൈറ്റും (482 MB ഇൻ users.ibd, 89 MB ഇൻ production.sqlite3) ഉള്ളിൽ ഇപ്പോഴും ജീവിച്ചിരിക്കുന്നു /proc/<PID>/fd/<FD>**.

ഘട്ടം 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) കണ്ടെയ്നർ FDകൾ അടയ്ക്കുന്നതിന് മുമ്പ്

എങ്കിൽ 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
(ശ്രദ്ധിക്കുക: PostgreSQL തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുന്നു .1, .2 വർക്കർ പ്രോസസ്സുകളിലുടനീളം സെഗ്‌മെൻ്റ് ഫയലുകൾ ചലനാത്മകമായി, അങ്ങനെ pg_dump കാഷെ ചെയ്യാത്ത പട്ടികകളിൽ പരാജയപ്പെടാം; ഒരു തത്സമയ SQL ചോദ്യം സംയോജിപ്പിച്ച് തുറന്നിരിക്കുന്ന ഓരോന്നും പകർത്തുന്നു /proc/<pid>/fd/* ഉടനീളം എല്ലാം postgres ചൈൽഡ് ബാക്കെൻഡ് PID-കൾ സാധ്യമായ പരമാവധി ടേബിൾ ഹീപ്പ് ഡാറ്റ സംരക്ഷിക്കുന്നു.)

ഘട്ടം 3: ഇല്ലാതാക്കിയ ഡോക്കർ വോളിയം വീണ്ടെടുക്കൽ ഓണാണ് ext4 അല്ലെങ്കിൽ XFS കണ്ടെയ്നർ നിർത്തിയ ശേഷം

ഓടിയാലോ docker compose down -v അല്ലെങ്കിൽ docker system prune --volumes, അതിനാൽ കണ്ടെയ്നർ ഇതിനകം നിർത്തി എല്ലാം /proc/<pid>/fd/ വിവരണങ്ങൾ അടച്ചിട്ടുണ്ടോ? നിങ്ങൾ ഇപ്പോൾ Linux ഹോസ്റ്റിൽ പശ്ചാത്തല ഡിസ്ക് എഴുതുന്നതിനെതിരെയുള്ള മത്സരത്തിലാണ്.

ഘട്ടം 1: Linux ഹോസ്റ്റ് ഫയൽസിസ്റ്റം 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. ** പാർട്ടീഷൻ റീഡ്-ഒൺലി റീമൗണ്ട് ചെയ്യുക (അല്ലെങ്കിൽ ഒരു റോ പാർട്ടീഷൻ ഇമേജ് SSH വഴി മറ്റൊരു മെഷീനിലേക്ക് സ്ട്രീം ചെയ്യുക)**:
  4. എങ്കിൽ /var/lib/docker സ്വന്തം ഡെഡിക്കേറ്റഡ് പാർട്ടീഷനിലോ എൽവിഎം വോള്യത്തിലോ ആണ് (ഉദാഹരണത്തിന് /dev/nvme0n1p2 അല്ലെങ്കിൽ /dev/mapper/vg0-docker), റീഡ്-ഓൺലി-ഉടൻ റീമൗണ്ട് ചെയ്യുക: 
    sudo mount -o remount,ro /var/lib/docker
  5. എങ്കിൽ /var/lib/docker റൂട്ടിലാണ് / വിഭജനം (/), കേർണൽ മാജിക് SysRq ട്രിഗർ ഉപയോഗിച്ച് റൂട്ട് പാർട്ടീഷൻ റീഡ്-ഒൺലി നിർബന്ധിച്ച് ശ്രമിക്കുക (echo u | sudo tee /proc/sysrq-trigger) അല്ലെങ്കിൽ sudo mount -o remount,ro /.
  6. നിങ്ങൾ ഒരു ക്ലൗഡ് വിപിഎസിലാണെങ്കിൽ (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
എല്ലാ ആഴ്‌ചയും, ഓട്ടത്തിനു ശേഷം അഡ്മിനിസ്ട്രേറ്റർമാർ പരിഭ്രാന്തരാകാറുണ്ട് docker volume rm app_db_data, കണ്ടുപിടിക്കാൻ മാത്രം find /var/lib/docker എന്ന് docker-compose.yml യഥാർത്ഥത്തിൽ സൃഷ്ടിച്ചിരുന്നു projectname_app_db_data (ഇത് ഇപ്പോഴും ഡിസ്കിൽ 100 ശതമാനം കേടുകൂടാതെയിരിക്കും) അതേസമയം app_db_data ആറ് മാസം മുമ്പ് ഉപയോഗിക്കാത്ത ഒരു പഴയ വോളിയമായിരുന്നു.

ഘട്ടം 3: അൺലിങ്ക് ചെയ്ത ഡോക്കർ വോളിയം ഡയറക്‌ടറികൾ വീണ്ടെടുക്കുന്നു ext4 ഉപയോഗിക്കുന്നത് ext4 ജേണൽ (ext4magic ഒപ്പം debugfs)

എപ്പോൾ docker volume rm ഇല്ലാതാക്കുന്നു /var/lib/docker/volumes/<vol_name>/_data ഒരു ന് ext4 ഫയൽസിസ്റ്റം, ext4 നേരിട്ടുള്ള ബ്ലോക്ക് പോയിൻ്ററുകളിൽ നിന്ന് പൂജ്യങ്ങൾ (i_block / പരിധി ട്രീ റൂട്ട്) ലൈവ് ഐനോഡ് പട്ടികയിൽ. എന്നിരുന്നാലും, 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
- -j /dev/shm/ext4_journal.copy: ഡോക്കർ നിർത്തിയ ഉടൻ തന്നെ നിങ്ങൾ റാമിൽ സംരക്ഷിച്ച ജേണൽ സ്നാപ്പ്ഷോട്ട് വായിക്കുന്നു. - -f var/lib/docker/volumes: കൃത്യമായ ഡോക്കർ വോളിയം ഡയറക്ടറി ട്രീ ലക്ഷ്യമിടുന്നു (ശ്രദ്ധിക്കുക: ലീഡിംഗ് ഒഴിവാക്കുക / ഇൻ ext4magic ആപേക്ഷിക പാതകൾ). - -a $(date -d "-15 minutes" +%s): പറയുന്നു ext4magic 15 മിനിറ്റ് മുമ്പ് സാധുതയുള്ള ഐനോഡ് പകർപ്പുകൾ ഉപയോഗിച്ച് ഡയറക്ടറി ട്രീ പുനർനിർമ്മിക്കുന്നതിന് (ആകസ്മികമായി ഇല്ലാതാക്കുന്നതിന് തൊട്ടുമുമ്പ്). - -r: ബ്ലോക്കുകളൊന്നും തിരുത്തിയെഴുതാത്ത പൂർണ്ണമായ ഡയറക്ടറികൾ വീണ്ടെടുക്കുന്നു; എങ്കിൽ -r ഭാഗികമായി മാറ്റിയെഴുതിയ ഫയലുകൾ നഷ്‌ടമായി, പകരം ഒരു രണ്ടാം പാസ് പ്രവർത്തിപ്പിക്കുക -r കൂടെ -m (മാജിക് കൊത്തുപണി + ജേണൽ ഹൈബ്രിഡ് മോഡ്).

ഘട്ടം 4: ജേണൽ പൊതിഞ്ഞിരിക്കുമ്പോൾ റോ SQLite, PostgreSQL, അല്ലെങ്കിൽ MySQL InnoDB ഫയലുകൾ കൊത്തിയെടുക്കുക (XFS അല്ലെങ്കിൽ ext4)

Warning

എന്തുകൊണ്ട് XFS പിന്തുണയ്ക്കുന്നില്ല ext4magic കൂടാതെ ഉടനടി വായിക്കാൻ മാത്രം അൺമൗണ്ടിംഗ് ആവശ്യമാണ്: വ്യത്യസ്തമായി ext4, അതിൻ്റെ ജേണലിലേക്ക് 256-ബൈറ്റ് ഐനോഡ് പകർപ്പുകൾ മുഴുവൻ എഴുതുന്നു, XFS മെറ്റാഡാറ്റ ഇൻ്റൻ്റ് ഡെൽറ്റകൾ ലോഗ് ചെയ്യുകയും ഫ്രീഡ് ഐനോഡ് ബി-ട്രീകൾ വീണ്ടും ഉപയോഗിക്കുകയും ചെയ്യുന്നു (agi). എങ്കിൽ /var/lib/docker ഒരു ഇരിക്കുന്നു XFS പാർട്ടീഷൻ (RHEL, Rocky Linux, AlmaLinux, Amazon Linux എന്നിവയിൽ സ്ഥിരസ്ഥിതി), അൺമൗണ്ട് ചെയ്യുന്നു /var/lib/docker അല്ലെങ്കിൽ റീമൗണ്ട് ചെയ്യുന്നു / കൊത്തുപണിക്ക് മുമ്പുള്ള ഏറ്റവും പ്രധാനപ്പെട്ട ഘട്ടം നിമിഷങ്ങൾക്കുള്ളിൽ വായിക്കാൻ മാത്രം.

ഹോസ്റ്റ് ഉപയോഗിക്കുകയാണെങ്കിൽ XFS അല്ലെങ്കിൽ എങ്കിൽ ext4 ജേണൽ ഇതിനകം ഐനോഡ് പോയിൻ്ററുകളിൽ പൊതിഞ്ഞിരിക്കുന്നു, റോ ഡിസ്ക് ഇമേജിന് നേരെ ഒപ്പും ഘടന കൊത്തുപണിയും ഉപയോഗിക്കുക (docker_host_raw.img):

  1. ** SQLite3 ഡാറ്റാബേസുകൾക്കായി (.sqlite, .db - ഉദാ., വോൾട്ട്‌വാർഡൻ, നെക്‌സ്റ്റ്‌ക്ലൗഡ്, ഹോം അസിസ്റ്റൻ്റ്, ഗിറ്റ, ഗ്രാഫാന)**: ഓരോ SQLite3 ഡാറ്റാബേസും അതിൻ്റെ ആദ്യ 4 കിലോബൈറ്റ് പേജിൻ്റെ ബൈറ്റ് 0-ൽ 16-ബൈറ്റ് ASCII തലക്കെട്ടോടെ ആരംഭിക്കുന്നു: 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 എല്ലാ ബി-ട്രീ ലീഫ് പേജുകളും പുനർനിർമ്മിക്കുന്നതിന്.

Tip

** കൃത്യമായി എങ്ങനെ കണക്കാക്കാം dd അൺലിങ്ക് ചെയ്യാത്ത SQLite3 ഫയലിൻ്റെ ബൈറ്റ് വലുപ്പം അതിൻ്റെ തലക്കെട്ടിൽ നിന്ന്**: ഒരിക്കൽ grep -ab "SQLite format 3" നിങ്ങൾക്ക് ആരംഭ ബൈറ്റ് ഓഫ്സെറ്റ് നൽകുന്നു OFFSET നിങ്ങളുടെ ഇല്ലാതാക്കിയ SQLite ഡാറ്റാബേസിൻ്റെ, റീഡ് ബൈറ്റുകൾ 16..17 (uint16 big-endian പേജ് വലുപ്പം, ഉദാ., 0x1000 = 4096 ബൈറ്റുകൾ) കൂടാതെ ബൈറ്റുകൾ 28..31 (uint32 ബിഗ്-എൻഡിയൻ പേജ് കൗണ്ട്, ഉദാ., 25000 പേജുകൾ) ഉപയോഗിക്കുന്നു hexdump -C -s OFFSET -n 32. ഗുണിക്കുന്നു Page Size x Page Count നിങ്ങൾക്ക് കടന്നുപോകാനുള്ള കൃത്യമായ ബൈറ്റ് ദൈർഘ്യം നൽകുന്നു dd (iflag=skip_bytes,count_bytes) ഫയൽ ഡിസ്കിൽ അടുത്തിരിക്കുമ്പോൾ.

  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), ഒരു സ്റ്റേറ്റ്ഫുൾ സെറ്റ് അല്ലെങ്കിൽ ഒരു മുഴുവൻ നെയിംസ്പേസ് (kubectl delete ns prod) സ്റ്റാൻഡ് എലോൺ ഡോക്കറിനേക്കാൾ വളരെ വ്യത്യസ്തമായ ഒരു ആർക്കിടെക്ചർ പിന്തുടരുന്നു.

രംഗം എ: പിവിസി കാണിക്കുന്നു Terminating (ഫൈനലൈസർ ലൈഫ് സേവർ)

പ്രവർത്തിപ്പിക്കുക: 

kubectl get pvc -n <namespace>
എങ്കിൽ STATUS കോളം പറയുന്നു Terminating, ആശ്വാസം ശ്വസിക്കുക: നിങ്ങളുടെ ഡാറ്റ ഇതുവരെ ഇല്ലാതാക്കിയിട്ടില്ല. - എന്തുകൊണ്ട്? Kubernetes 1.9 സ്വയമേവ ഉൾപ്പെടുന്നതിനാൽ സൃഷ്ടിച്ച എല്ലാ കുബർനെറ്റസ് PVC finalizers: [kubernetes.io/pvc-protection]. - ഒരു പോഡ് ഇപ്പോഴും ആ PVC മൌണ്ട് ചെയ്യുന്നിടത്തോളം, Kubernetes കൺട്രോളർ PVC ഇല്ലാതാക്കൽ പൂർത്തിയാക്കാൻ വിസമ്മതിക്കുകയും ** CSI ഡ്രൈവർമാരെ വിളിക്കുകയുമില്ല. DeleteVolume RPC**. - ** ഉടനടി പ്രവർത്തനം**: പോഡ് ഇല്ലാതാക്കുകയോ പുനരാരംഭിക്കുകയോ ചെയ്യുക, കൂടാതെ അരുത് ഫൈനലൈസർ പാച്ച് ഔട്ട് ചെയ്യുക. പ്രവർത്തിക്കുന്ന Pod-ൽ നിന്നുള്ള എല്ലാ ഡാറ്റയും നിങ്ങളുടെ ലോക്കൽ മെഷീനിലേക്കോ ഒരു S3 ബക്കറ്റിലേക്കോ ഉടനടി പകർത്തുക: 
# 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

സാഹചര്യം ബി: പിവിസി ഇല്ലാതാക്കി, കൂടാതെ kubectl get pv ഇൻ പെർസിസ്റ്റൻ്റ് വോളിയം കാണിക്കുന്നു Released സംസ്ഥാന (ReclaimPolicy: Retain)

പ്രവർത്തിപ്പിക്കുക: 

kubectl get pv
നിങ്ങളുടെ പെർസിസ്റ്റൻ്റ് വോളിയമാണെങ്കിൽ (pv-prod-postgres) എന്നതിൽ ഇപ്പോഴും പട്ടികപ്പെടുത്തിയിട്ടുണ്ട് STATUS: Released (കാരണം അതിൻ്റെ സ്റ്റോറേജ് ക്ലാസ് ഉപയോഗിച്ചു reclaimPolicy: Retain), നിങ്ങളുടെ ഡാറ്റയുടെ 100 ശതമാനം ഇപ്പോഴും അണ്ടർലൈയിംഗ് ഡിസ്കിൽ സ്പർശിക്കാതെ ഇരിക്കുന്നു. എന്നിരുന്നാലും, ഒരു പുതിയ PVC യെ ബന്ധിപ്പിക്കാൻ കുബെർനെറ്റസ് വിസമ്മതിക്കുന്നു Released പിവിയിൽ ഇപ്പോഴും എ അടങ്ങിയിരിക്കുന്നതിനാൽ പി.വി spec.claimRef പഴയ ഇല്ലാതാക്കിയ PVC-കളിലേക്ക് വിരൽ ചൂണ്ടുന്നു UID.

എങ്ങനെ ഉണ്ടാക്കാം എ Released പി.വി Available 10 സെക്കൻഡിനുള്ളിൽ പൂജ്യം ഡാറ്റ നഷ്‌ടത്തോടെ: 1. PersistentVolume ഒബ്‌ജക്‌റ്റ് എഡിറ്റുചെയ്‌ത് ഇല്ലാതാക്കുക spec.claimRef തടയുക: 

kubectl patch pv <your-pv-name> --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'
2. ഓടുക kubectl get pv വീണ്ടും: സ്റ്റാറ്റസ് ഉടനടി ** എന്നതിൽ നിന്ന് മാറുന്നുReleased** മുതൽ ** വരെAvailable**. 3. നിങ്ങളുടെ പുനർനിർമ്മിക്കുക PersistentVolumeClaim (വ്യക്തമാക്കുന്നു volumeName: <your-pv-name> ഒപ്പം പൊരുത്തപ്പെടുന്ന ശേഷി/സ്റ്റോറേജ്ക്ലാസ്നെയിം). എല്ലാ ഫയലുകളും കേടുപാടുകൾ കൂടാതെ നിലവിലുള്ള പിവിയുമായി ഇത് ഉടനടി ബന്ധിപ്പിക്കും.

സിനാരിയോ സി: ഒരു തുടച്ചുമാറ്റപ്പെട്ട കുബർനെറ്റസ് ക്ലസ്റ്റർ അവസ്ഥ പുനഃസ്ഥാപിക്കുന്നു etcd സ്നാപ്പ്ഷോട്ട് (etcdctl snapshot restore)

ആരെങ്കിലും ഓടിയാലോ kubectl delete namespace prod അല്ലെങ്കിൽ helm uninstall സ്വയം നിയന്ത്രിതത്തിൽ 200 കുബർനെറ്റസ് മാനിഫെസ്റ്റുകൾ, രഹസ്യങ്ങൾ, കോൺഫിഗ്മാപ്പുകൾ, പിവി നിർവചനങ്ങൾ എന്നിവ ഇല്ലാതാക്കി 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 അക്ഷരത്തെറ്റിന് ഒരിക്കലും ഒരു തത്സമയ വോളിയം ഇല്ലാതാക്കാൻ കഴിയില്ല:

  • ** എല്ലാ പ്രൊഡക്ഷൻ കുബർനെറ്റുകളും മാറ്റുക StorageClass നിന്ന് reclaimPolicy: Delete വരെ reclaimPolicy: Retain**: ഡിഫോൾട്ടായി, ബിൽറ്റ്-ഇൻ ക്ലൗഡ് സ്റ്റോറേജ് ക്ലാസുകൾ (gp2, gp3, standard-rwo) സ്ഥിരസ്ഥിതി reclaimPolicy: Delete, അതായത് ഒരു പിവിസി ഇല്ലാതാക്കുന്നത് ക്ലൗഡ് ഡിസ്കിനെ നശിപ്പിക്കുന്നു. എ സൃഷ്ടിക്കുക StorageClass കൂടെ reclaimPolicy: Retain (അല്ലെങ്കിൽ നിലവിലുള്ള പിവികൾ പാച്ച് ചെയ്യുക kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') അതിനാൽ ഒരു പിവിസി അല്ലെങ്കിൽ നെയിംസ്പേസ് ഇല്ലാതാക്കുന്നത് ഒരിക്കലും അടിസ്ഥാന ബ്ലോക്ക് വോളിയം ഇല്ലാതാക്കില്ല.
  • ** AWS EBS റീസൈക്കിൾ ബിൻ / GCP സ്നാപ്പ്ഷോട്ട് ഷെഡ്യൂളുകൾ / Velero CSI സ്നാപ്പ്ഷോട്ടുകൾ ഉപയോഗിച്ച് പ്രവർത്തനക്ഷമമാക്കുക**: AWS EBS റീസൈക്കിൾ ബിൻ പ്രവർത്തനക്ഷമമാക്കുന്നത് CSI ഡ്രൈവർ വിളിച്ചാലും 7 മുതൽ 30 ദിവസം വരെ ഇല്ലാതാക്കിയ EBS വോളിയം നിലനിർത്തുന്നു 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 ജീവന് ഭീഷണി അല്ലെങ്കിൽ നിർണായകമായ NHS ഇൻഫ്രാസ്ട്രക്ചർ. യുകെ GDPR-ന് കീഴിൽ, വീണ്ടെടുക്കാവുന്ന ബാക്കപ്പ് ഇല്ലാതെ വ്യക്തിഗത ഡാറ്റയുടെ ശാശ്വതമായ നാശത്തിനോ ലഭ്യത നഷ്ടപ്പെടുന്നതിനോ ICO-ലേക്കുള്ള 72 മണിക്കൂർ ലംഘന അറിയിപ്പ് വിലയിരുത്തേണ്ടതുണ്ട് (0303 123 1113).
  • യൂറോപ്യൻ യൂണിയൻ: ഡയൽ ചെയ്യുക 112 എല്ലാ EU അംഗരാജ്യങ്ങളിലും ഉടനീളം. NIS2 ഡയറക്‌ടീവിന് കീഴിലുള്ള സ്ഥാപനങ്ങൾ, ഗുരുതരമായ സേവന തടസ്സം ഉണ്ടായാൽ 24 മണിക്കൂറിനുള്ളിൽ അവരുടെ ദേശീയ CSIRT-ന് ഒരു മുൻകൂർ മുന്നറിയിപ്പ് സമർപ്പിക്കണം, കൂടാതെ സ്ഥിരമായ വ്യക്തിഗത ഡാറ്റാ നഷ്ടം GDPR ആർട്ടിക്കിൾ 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` (ഇത് ആദ്യം നിർത്തിയ എല്ലാ കണ്ടെയ്‌നറുകളും ഇല്ലാതാക്കുന്നു പിന്നെ ഒരു കണ്ടെയ്‌നറിലും ഘടിപ്പിച്ചിട്ടില്ലാത്ത എല്ലാ വോള്യങ്ങളും ഇല്ലാതാക്കുന്നു), നിർത്തിയ കണ്ടെയ്‌നർ നീക്കം ചെയ്‌ത് ഉടൻ തന്നെ തുടച്ചുനീക്കപ്പെടുന്ന മില്ലിസെക്കൻഡ് വോളിയം "തൂങ്ങിക്കിടക്കുന്നു".

മാക്കിലെ ഡോക്കർ ഡെസ്ക്ടോപ്പിനുള്ളിൽ ഇല്ലാതാക്കിയ ഡോക്കർ വോളിയം വീണ്ടെടുക്കാനാകുമോ (Apple Silicon / Intel) അല്ലെങ്കിൽ വിൻഡോസ് (WSL2)?

അതെ, നിങ്ങൾ ഉടൻ തന്നെ ഡോക്കർ ഡെസ്ക്ടോപ്പിൽ നിന്ന് പുറത്തുകടക്കുകയാണെങ്കിൽ വെർച്വൽ മെഷീൻ പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു `fstrim` വെർച്വൽ ഡിസ്കിനെതിരെ. MacOS-ൽ, ഡോക്കർ എല്ലാ Linux വോള്യങ്ങളും ഉള്ളിൽ സംഭരിക്കുന്നു `-/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw`; Windows WSL2-ൽ, ഉള്ളിൽ `%LocalAppData%\Docker\wsl\disk\docker_data.vhdx`. അത് പകർത്തുക `.raw` അല്ലെങ്കിൽ `.vhdx` ഉടനടി ഒരു ബാഹ്യ SSD-ലേക്ക് ഫയൽ ചെയ്യുക, അത് ലിനക്സിൽ വായിക്കാൻ മാത്രം അറ്റാച്ചുചെയ്യുക (ഉപയോഗിക്കുക `losetup -Pr` വേണ്ടി `.raw` അല്ലെങ്കിൽ `qemu-nbd -r` വേണ്ടി `.vhdx`), ഓടിക്കുക `ext4magic` അല്ലെങ്കിൽ `PhotoRec` വെർച്വലിനെതിരെ `ext4` ഉള്ളിൽ വിഭജനം.

ഞാൻ ഒരു കുബർനെറ്റസ് സ്റ്റേറ്റ്ഫുൾസെറ്റ് ഇല്ലാതാക്കിയാലോ kubectl delete statefulset postgres? അത് എൻ്റെ പിവിസികളും ഇല്ലാതാക്കിയോ?

ഇല്ല. കുബർനെറ്റസിൽ സ്ഥിരസ്ഥിതിയായി (അല്ലാതെ `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` കുബെർനെറ്റസ് 1.27+ ൽ വ്യക്തമായി കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു), പ്രവർത്തിക്കുന്നു `kubectl delete statefulset` സ്റ്റേറ്റ്ഫുൾസെറ്റ് കൺട്രോളറും അതിൻ്റെ പോഡുകളും ഇല്ലാതാക്കുന്നു, എല്ലാം ഉപേക്ഷിക്കുന്നു `PersistentVolumeClaims` (`data-postgres-0`, `data-postgres-1`) കൂടാതെ അവയുടെ അടിസ്ഥാന ഡാറ്റ 100 ശതമാനം കേടുകൂടാതെയിരിക്കും. നിങ്ങളുടെ വീണ്ടും പ്രയോഗിക്കുക `StatefulSet` YAML മാനിഫെസ്‌റ്റ് അതേ പേരിൽ ഒപ്പം `volumeClaimTemplates`, കൂടാതെ പുതിയ പോഡുകൾ നിലവിലുള്ളവയുമായി സ്വയമേവ വീണ്ടും അറ്റാച്ചുചെയ്യും `data-postgres-0` പിവിസികൾ.

ഒരു ഡോക്കറിനുള്ളിലെ ഫയലുകൾ എങ്ങനെ ആക്സസ് ചെയ്യാം overlay2 കണ്ടെയ്നർ ആരംഭിക്കാൻ വിസമ്മതിക്കുമ്പോൾ ഡയറക്ടറി (CrashLoopBackOff / Exited (1))?

തകർന്ന കണ്ടെയ്നർ ഇല്ലാതാക്കരുത്. നിർത്തിയ കണ്ടെയ്നർ നിലനിൽക്കുന്നിടത്തോളം `docker ps -a`, അതിൻ്റെ റൈറ്റബിൾ ലെയറും വോളിയം മൗണ്ടുകളും ഡിസ്കിൽ പൂർണ്ണമായും കേടുകൂടാതെയിരിക്കും. നിങ്ങൾക്ക് ഒന്നുകിൽ ഉപയോഗിച്ച് നിർത്തിയ കണ്ടെയ്‌നറിൽ നിന്ന് നേരിട്ട് ഫയലുകൾ പകർത്താനാകും `docker cp :/var/lib/postgresql/data /root/rescued_data`, അല്ലെങ്കിൽ അതിൻ്റെ കൃത്യമായ ഹോസ്റ്റ് കണ്ടെത്തുക `overlay2` ഓടിക്കൊണ്ടുള്ള പാത `docker inspect --format '{{.GraphDriver.Data.UpperDir}}'` ആ ഡയറക്ടറി നേരിട്ട് വായിക്കുകയും ചെയ്യുക `root`.

ആരെങ്കിലും ഒരു കുബർനെറ്റിനെ ഇല്ലാതാക്കിയാലോ Namespace (kubectl delete ns prod) കൂടാതെ എല്ലാ പിവിസികൾക്കും ഉണ്ടായിരുന്നു reclaimPolicy: Delete AWS EBS അല്ലെങ്കിൽ GCP-യിൽ?

ക്ലൗഡ് CSI ഡ്രൈവർ ആണെങ്കിൽ (`ebs.csi.aws.com` അല്ലെങ്കിൽ `pd.csi.storage.gke.io`) ഇതിനകം നടപ്പിലാക്കി `DeleteVolume` കാരണം `reclaimPolicy` ആയിരുന്നു `Delete`, മൂന്ന് ക്ലൗഡ്-ലെവൽ സുരക്ഷാ വലകൾ ഉടനടി പരിശോധിക്കുക: (1) AWS EC2 കൺസോളിൽ EBS വോള്യങ്ങൾക്കുള്ള **AWS റീസൈക്കിൾ ബിൻ പരിശോധിക്കുക* (2) ഏറ്റവും പുതിയ ഓട്ടോമേറ്റഡ് വോളിയം സ്നാപ്പ്ഷോട്ടിനായി **AWS ബാക്കപ്പ് / DLM / GCP സ്നാപ്പ്ഷോട്ട് ഷെഡ്യൂളുകൾ** പരിശോധിക്കുക; കൂടാതെ (3) നിങ്ങളുടെ ഡാറ്റാബേസ് WAL/ബിൻലോഗുകൾ സ്ട്രീം ചെയ്യുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക (`WAL-G`, `pgBackRest`, `Litestream`) ഒരു S3/GCS ബക്കറ്റിലേക്ക്.

ബന്ധപ്പെട്ട ഗൈഡുകൾ

ഉറവിടങ്ങളും ഔദ്യോഗിക മാർഗനിർദേശങ്ങളും

  • കുബർനെറ്റസ് ഔദ്യോഗിക ഡോക്യുമെൻ്റേഷൻ (kubernetes.io / ക്ലൗഡ് നേറ്റീവ് കംപ്യൂട്ടിംഗ് ഫൗണ്ടേഷൻ): ഉപയോഗ സംരക്ഷണത്തിലുള്ള സംഭരണ വസ്തു (kubernetes.io/pvc-protection ഫൈനലൈസറുകൾ), പെർസിസ്റ്റൻ്റ് വോളിയങ്ങൾ വീണ്ടെടുക്കുന്നു (Retain vs. Delete), കൂടാതെ പ്രവർത്തനം etcd കുബർനെറ്റസിനുള്ള ക്ലസ്റ്ററുകൾ (etcdctl snapshot restore).
  • ഡോക്കർ ഇൻക്. (docs.docker.com): ഡോക്കറിൽ ഡാറ്റ നിയന്ത്രിക്കുക: വോള്യങ്ങൾ, ബൈൻഡ് മൗണ്ടുകൾ, overlay2 സ്റ്റോറേജ് ഡ്രൈവർ ആർക്കിടെക്ചർ, പ്രൂൺ റഫറൻസ്.
  • ലിനക്സ് കേർണൽ ഓർഗനൈസേഷൻ (kernel.org): ദി /proc ഫയൽസിസ്റ്റം (procfs ഇതിലൂടെ ഫയൽ ഡിസ്ക്രിപ്റ്റർ റിക്കവറി തുറക്കുക /proc/<pid>/fd/) കൂടാതെ Ext4 ജേർണൽ സ്പെസിഫിക്കേഷൻ.
  • ext4magic പ്രോജക്റ്റ് ഡോക്യുമെൻ്റേഷൻ (ext4magic.sourceforge.net): Forensic Inode, Journal Transaction Recovery on Ext3/Ext4 ഫയൽസിസ്റ്റംസ്.
  • നാഷണൽ ഇൻസ്റ്റിറ്റ്യൂട്ട് ഓഫ് സ്റ്റാൻഡേർഡ്സ് ആൻഡ് ടെക്നോളജി (NIST) (യുണൈറ്റഡ് സ്റ്റേറ്റ്സ്): പ്രത്യേക പ്രസിദ്ധീകരണം 800-190: ആപ്ലിക്കേഷൻ കണ്ടെയ്നർ സെക്യൂരിറ്റി ഗൈഡ് & സംഭവ വീണ്ടെടുക്കൽ.