ਡੌਕਰ ਜਾਂ ਕੁਬਰਨੇਟਸ ਉਤਪਾਦਨ ਵਾਲੀਅਮ ਮਿਟਾਇਆ ਗਿਆ: ਬਚਾਅ ਕਰਨਾ 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 ਲੌਗ ਬਲੋਟ, ਅਤੇ ਜ਼ੀਰੋ-ਸਪੇਸ ਰਿਕਵਰੀ; ਕੰਟੇਨਰਾਂ ਦੇ ਬਾਹਰ ਬੇਅਰ-ਮੈਟਲ ਲੀਨਕਸ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਣ ਲਈ, ਵੇਖੋ 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);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 ਅਜੇ ਵੀ ਪੀਵੀਸੀ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ। Pod ਨੂੰ ਉਦੋਂ ਤੱਕ ਨਾ ਮਿਟਾਓ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਚੱਲ ਰਹੇ Pod ਵਿੱਚੋਂ ਡੇਟਾ ਦੀ ਨਕਲ ਨਹੀਂ ਕਰਦੇ।
7. ** ਅੰਡਰਲਾਈੰਗ ਬਲਾਕ ਭਾਗ ਦੀ ਤਸਵੀਰ (dd / ddrescue SSH ਉੱਤੇ) ਇੱਕ ਬਾਹਰੀ ਡਿਸਕ ਜਾਂ ਵੱਖਰਾ ਕਲਾਉਡ ਵਾਲੀਅਮ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ 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 ਪਰਤ, ਜਾਂ ਕੁਬਰਨੇਟਸ ਪੀਵੀਸੀ ਟ੍ਰਾਈਜ¶

ਕੀ ਕੰਟੇਨਰ ਪ੍ਰਕਿਰਿਆ ਅਜੇ ਵੀ ਜ਼ਿੰਦਾ ਹੈ, ਕੀ ਵਾਲੀਅਮ ਨੂੰ ਲੋਕਲ ਡਿਸਕ ਜਾਂ ਕਲਾਉਡ CSI ਸਟੋਰੇਜ ਦੁਆਰਾ ਬੈਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਕਿਹੜਾ ਫਾਈਲ ਸਿਸਟਮ ਹੋਸਟ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਆਧਾਰ 'ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਜ਼ੀਰੋ-ਨੁਕਸਾਨ ਰਿਕਵਰੀ ਮਾਰਗ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਇਸ ਫਲੋਚਾਰਟ ਦੀ ਵਰਤੋਂ ਕਰੋ। /var/lib/docker:

flowchart TD
    Start["ਡੌਕਰ ਜਾਂ ਕੁਬਰਨੇਟਸ ਡਿਲੀਟ ਕਮਾਂਡ ਤੋਂ ਬਾਅਦ ਉਤਪਾਦਨ ਡੇਟਾ ਗੁੰਮ ਹੈ"] --> WhichEnv{"ਕਿਹੜੇ ਪਲੇਟਫਾਰਮ ਅਤੇ ਕਮਾਂਡ ਨੇ ਨੁਕਸਾਨ ਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ?"}

    WhichEnv -->|"ਡੌਕਰ: ਕੰਟੇਨਰ ਅਜੇ ਵੀ ਚੱਲ ਰਿਹਾ ਹੈ (ਵਾਲੀਅਮ/ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਅਣਲਿੰਕ ਕੀਤੀਆਂ ਫਾਈਲਾਂ)"| ProcRescue["sudo lsof +L1 ਅਤੇ /proc/PID/fd/N ਜਾਂ /proc/PID/root/ ਰਾਹੀਂ ਅਨਲਿੰਕਡ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਨੂੰ ਖੋਲ੍ਹੋ।"]

    WhichEnv -->|"ਡੌਕਰ: ਕੰਟੇਨਰ ਰੋਕਿਆ ਗਿਆ ਅਤੇ ਵਾਲੀਅਮ ਮਿਟਾਇਆ ਗਿਆ (ਕੰਪੋਜ਼ ਡਾਊਨ -v / ਪ੍ਰੂਨ --ਵੋਲਿਊਮ)"| StopDocker["ਤੁਰੰਤ ਚਲਾਓ: sudo systemctl stop docker.socket docker containerd"]

    WhichEnv -->|"ਕੁਬਰਨੇਟਸ: kubectl ਮਿਟਾਓ pvc / pv / statefulset / namespace"| K8sCheck{"ਕੀ ਪੌਡ ਅਜੇ ਵੀ ਚੱਲ ਰਿਹਾ ਹੈ ਜਾਂ ਕੀ ਪੀਵੀਸੀ ਸਮਾਪਤ ਹੋਣ ਵਿੱਚ ਫਸਿਆ ਹੋਇਆ ਹੈ?"}

    K8sCheck -->|"ਹਾਂ: ਪੌਡ ਅਜੇ ਵੀ ਚੱਲ ਰਿਹਾ ਹੈ (ਫਾਈਨਲਾਈਜ਼ਰ ਬਲਾਕਿੰਗ ਸੀਐਸਆਈ ਡਿਲੀਟ)"| K8sExec["Pod ਨੂੰ ਨਾ ਮਿਟਾਓ -> kubectl exec/pg_dump/tar ਨੂੰ ਸਥਾਨਕ ਡਿਸਕ ਉੱਤੇ ਤੁਰੰਤ ਚਲਾਓ।"]
    K8sCheck -->|"ਨਹੀਂ: Pod Gone -> ਚੈੱਕ kubectl get pv"| ReclaimCheck{"ਪੀਵੀ ਰੀਕਲੇਮ ਪਾਲਿਸੀ ਕੀ ਸੀ?"}

    ReclaimCheck -->|"ਬਰਕਰਾਰ ਰੱਖੋ (PV ਸਥਿਤੀ = ਜਾਰੀ)"| ClearClaimRef["100% ਡਾਟਾ ਬਰਕਰਾਰ -> spec.claimRef.uid ਨੂੰ ਹਟਾਉਣ ਲਈ PV ਸੰਪਾਦਿਤ ਕਰੋ -> ਨਵੇਂ PVC ਨਾਲ ਮੁੜ-ਬਾਈਡ ਕਰੋ"]
    ReclaimCheck -->|"ਮਿਟਾਓ (ਕਲਾਊਡ EBS / PD / Longhorn / Local-Path)"| CloudOrLocal{"ਕਲਾਉਡ CSI ਵਾਲੀਅਮ ਜਾਂ ਸਥਾਨਕ ਹੋਸਟ ਡਿਸਕ?"}

    CloudOrLocal -->|"ਕਲਾਉਡ CSI (AWS EBS / GCP / Azure / Ceph)"| CloudSnap["ਕਲਾਉਡ ਕੰਸੋਲ ਰੀਸਾਈਕਲ ਬਿਨ / ਆਟੋਮੇਟਿਡ EBS ਸਨੈਪਸ਼ਾਟ / Ceph RBD ਰੱਦੀ (rbd ਰੱਦੀ ls) ਦੀ ਜਾਂਚ ਕਰੋ"]
    CloudOrLocal -->|"ਲੋਕਲ ਨੋਡ ਡਿਸਕ (ਲੋਕਲ-ਪਾਥ / ਹੋਸਟਪਾਥ)"| StopDocker

    StopDocker --> RemountRO["ਰੀਮਾਉਂਟ ਹੋਸਟ ਪਾਰਟੀਸ਼ਨ ਰੀਡ-ਓਨਲੀ (ਮਾਊਟ -ਓ ਰੀਮਾਉਂਟ,ro) ਜਾਂ SSH ਉੱਤੇ ਸਟ੍ਰੀਮ ਬਲੌਕ ਚਿੱਤਰ"]
    RemountRO --> HostFS{"ਕੀ ਫਾਈਲਸਿਸਟਮ ਹੋਸਟ /var/lib/docker?"}
    HostFS -->|"ext4"| Ext4Rec["debugfs / ext4magic ਜਰਨਲ ਇਨੋਡ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਰੋਲਬੈਕ (-ਇੱਕ ਟਾਈਮਸਟੈਂਪ) ਦੀ ਵਰਤੋਂ ਕਰੋ"]
    HostFS -->|"XFS / Btrfs"| CarveRec["SQLite, Postgres Heap, ਜਾਂ InnoDB .ibd ਲਈ Btrfs ਰੂਟਸ / 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) ਉਸ ਆਈਨੋਡ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਬਾਹਰ ਆ ਜਾਂਦਾ ਹੈ।

ਕਦਮ 1: ਹੋਸਟ ਪ੍ਰਕਿਰਿਆ ID ਲੱਭੋ (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ਕੰਟੇਨਰ FD ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ¶

ਜੇ 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. ਰੀਡ-ਓਨਲੀ ਭਾਗ ਨੂੰ ਮੁੜ ਮਾਊਂਟ ਕਰੋ (ਜਾਂ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਲਈ SSH ਉੱਤੇ ਇੱਕ ਕੱਚਾ ਭਾਗ ਚਿੱਤਰ ਸਟ੍ਰੀਮ ਕਰੋ):
4. ਜੇ /var/lib/docker ਇਸਦੇ ਆਪਣੇ ਸਮਰਪਿਤ ਭਾਗ ਜਾਂ LVM ਵਾਲੀਅਮ 'ਤੇ ਹੈ (ਉਦਾਹਰਨ ਲਈ /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. ਜੇਕਰ ਤੁਸੀਂ ਕਲਾਊਡ 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: ਅਨਲਿੰਕਡ ਡੌਕਰ ਵਾਲੀਅਮ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ 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

ਕਦਮ 4: ਕੱਚੀ SQLite, PostgreSQL, ਜਾਂ MySQL InnoDB ਫਾਈਲਾਂ ਨੂੰ ਉਕਰਾਉਣਾ ਜਦੋਂ ਜਰਨਲ ਨੂੰ ਸਮੇਟਿਆ ਜਾਂਦਾ ਹੈ (XFS ਜਾਂ ext4)¶

ਜੇ ਹੋਸਟ ** ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ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 ਹਰ ਬਰਕਰਾਰ ਬੀ-ਟ੍ਰੀ ਲੀਫ ਪੇਜ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ।

1. ** MySQL / MariaDB InnoDB ਲਈ (.ibd ਟੇਬਲ ਫਾਈਲਾਂ): ਹਰ InnoDB .ibd ਸਾਰਣੀ ਵਿੱਚ ਕ੍ਰਮਵਾਰ ਹੁੰਦਾ ਹੈ 16 KB (16,384 ਬਾਈਟ) ਵਾਲੇ ਪੰਨੇ FIL_PAGE_INDEX (0x45BF) ਸਿਰਲੇਖ ਅਤੇ ਸਾਰਣੀ ਵਿਲੱਖਣ ਹੈ space_id. ਪਰਕੋਨਾ / ਟਵਿਨਡੀਬੀ ** ਦੀ ਵਰਤੋਂ ਕਰੋ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: ਕੁਬਰਨੇਟਸ ਪੀਵੀਸੀ, ਪੀਵੀ, ਅਤੇ etcd ਸਨੈਪਸ਼ਾਟ ਐਮਰਜੈਂਸੀ ਰਿਕਵਰੀ¶

ਕੁਬਰਨੇਟਸ ਵਿੱਚ (EKS, GKE, AKS, k3s, RKE2, kubeadm, OpenShift), ਗਲਤੀ ਨਾਲ ਇੱਕ Persistent VolumeClaim ਨੂੰ ਮਿਟਾਉਣਾ (kubectl delete pvc), ਇੱਕ ਸਟੇਟਫੁਲਸੈੱਟ, ਜਾਂ ਇੱਕ ਪੂਰਾ ਨੇਮਸਪੇਸ (kubectl delete ns prod) ਸਟੈਂਡਅਲੋਨ ਡੌਕਰ ਨਾਲੋਂ ਬਹੁਤ ਵੱਖਰੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।

ਦ੍ਰਿਸ਼ A: ਪੀਵੀਸੀ ਦਿਖਾਉਂਦਾ ਹੈ Terminating (ਫਾਈਨਲਾਈਜ਼ਰ ਲਾਈਫਸੇਵਰ)¶

ਚਲਾਓ:

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: ਪੀਵੀਸੀ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ kubectl get pv ਵਿੱਚ ਪਰਸਿਸਟੈਂਟ ਵਾਲੀਅਮ ਦਿਖਾਉਂਦਾ ਹੈ Released ਰਾਜ (ReclaimPolicy: Retain)¶

ਚਲਾਓ:

kubectl get pv

ਕਿਵੇਂ ਏ Released ਪੀ.ਵੀ Available ਜ਼ੀਰੋ ਡਾਟਾ ਨੁਕਸਾਨ ਦੇ ਨਾਲ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ: 1. Persistent Volume ਆਬਜੈਕਟ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੋ ਅਤੇ ਮਿਟਾਓ spec.claimRef ਬਲਾਕ:

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

ਦ੍ਰਿਸ਼ C: ਇੱਕ ਤੋਂ ਪੂੰਝੇ ਹੋਏ Kubernetes ਕਲੱਸਟਰ ਅਵਸਥਾ ਨੂੰ ਮੁੜ ਬਹਾਲ ਕਰਨਾ 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, ਭਾਵ ਇੱਕ PVC ਨੂੰ ਮਿਟਾਉਣਾ ਕਲਾਉਡ ਡਿਸਕ ਨੂੰ ਨਸ਼ਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਬਣਾਓ ਏ StorageClass ਨਾਲ reclaimPolicy: Retain (ਜਾਂ ਮੌਜੂਦਾ ਪੀਵੀ ਨੂੰ ਇਸ ਨਾਲ ਪੈਚ ਕਰੋ kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}') ਇਸਲਈ ਪੀਵੀਸੀ ਜਾਂ ਨੇਮਸਪੇਸ ਨੂੰ ਮਿਟਾਉਣਾ ਕਦੇ ਵੀ ਅੰਡਰਲਾਈੰਗ ਬਲਾਕ ਵਾਲੀਅਮ ਨੂੰ ਨਹੀਂ ਮਿਟਾਉਂਦਾ ਹੈ।
• CSI ਸਨੈਪਸ਼ਾਟ ਨਾਲ AWS EBS ਰੀਸਾਈਕਲ ਬਿਨ / GCP ਸਨੈਪਸ਼ਾਟ ਸ਼ਡਿਊਲ / ਵੇਲੇਰੋ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ: AWS EBS ਰੀਸਾਈਕਲ ਬਿਨ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਨਾਲ 7 ਤੋਂ 30 ਦਿਨਾਂ ਲਈ ਕਿਸੇ ਵੀ ਮਿਟਾਏ ਗਏ EBS ਵਾਲੀਅਮ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਭਾਵੇਂ CSI ਡਰਾਈਵਰ ਕਾਲ ਕਰਦਾ ਹੈ DeleteVolume.
• ** ਕਦੇ ਨਾ ਵਰਤੋ docker system prune --volumes ਆਟੋਮੇਟਿਡ ਕਲੀਨਅਪ ਸਕ੍ਰਿਪਟਾਂ ਜਾਂ ਸੀਆਈ/ਸੀਡੀ ਰਨਰਜ਼** ਵਿੱਚ: ਜੇਕਰ ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਕੰਟੇਨਰ ਸੰਖੇਪ ਵਿੱਚ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ (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 ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਖਤਰੇ ਲਈ। UK GDPR ਦੇ ਤਹਿਤ, ਇੱਕ ਰਿਕਵਰੀਯੋਗ ਬੈਕਅੱਪ ਦੇ ਬਿਨਾਂ ਨਿੱਜੀ ਡੇਟਾ ਦੀ ਸਥਾਈ ਤਬਾਹੀ ਜਾਂ ਉਪਲਬਧਤਾ ਦੇ ਨੁਕਸਾਨ ਲਈ ICO (0303 123 1113)।
• ਯੂਰਪੀਅਨ ਯੂਨੀਅਨ: ਡਾਇਲ ਕਰੋ 112 ਸਾਰੇ ਈਯੂ ਮੈਂਬਰ ਰਾਜਾਂ ਵਿੱਚ। 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` ਵਰਚੁਅਲ ਡਿਸਕ ਦੇ ਵਿਰੁੱਧ. ਮੈਕੋਸ 'ਤੇ, ਡੌਕਰ ਸਾਰੇ ਲੀਨਕਸ ਵਾਲੀਅਮ ਨੂੰ ਅੰਦਰ ਸਟੋਰ ਕਰਦਾ ਹੈ `-/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` ਅੰਦਰ ਵੰਡ.

ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਮੈਂ ਕੁਬਰਨੇਟਸ ਸਟੇਟਫੁਲਸੈੱਟ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਹੈ kubectl delete statefulset postgres? ਕੀ ਇਸਨੇ ਮੇਰੇ ਪੀਵੀਸੀ ਵੀ ਮਿਟਾ ਦਿੱਤੇ?¶

ਨੰ. ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ (ਜਦੋਂ ਤੱਕ `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete` Kubernetes 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 ਰੀਸਾਈਕਲ ਬਿਨ** ਦੀ ਜਾਂਚ ਕਰੋ (ਜੇ ਖਾਤੇ/ਟੈਗਾਂ 'ਤੇ ਕੋਈ ਧਾਰਨ ਨਿਯਮ ਕਿਰਿਆਸ਼ੀਲ ਸੀ, ਤਾਂ ਹਟਾਇਆ ਗਿਆ EBS ਵਾਲੀਅਮ ਰੀਸਾਈਕਲ ਬਿਨ ਵਿੱਚ ਬੈਠਦਾ ਹੈ ਅਤੇ 1 ਕਲਿੱਕ ਵਿੱਚ ਰੀਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ); (2) ਸਭ ਤੋਂ ਤਾਜ਼ਾ ਸਵੈਚਲਿਤ ਵੌਲਯੂਮ ਸਨੈਪਸ਼ਾਟ ਲਈ **AWS ਬੈਕਅੱਪ / DLM / GCP ਸਨੈਪਸ਼ਾਟ ਸਮਾਂ-ਸੂਚੀ** ਦੀ ਜਾਂਚ ਕਰੋ; ਅਤੇ (3) ਜਾਂਚ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ WAL/binlogs ਨੂੰ ਸਟ੍ਰੀਮ ਕਰ ਰਿਹਾ ਸੀ (`WAL-G`, `pgBackRest`, `Litestream`) ਨੂੰ ਇੱਕ S3/GCS ਬਾਲਟੀ।

ਸੰਬੰਧਿਤ ਗਾਈਡ¶

• ਸਰਵਰ ਡਿਸਕ 100% ਪੂਰੀ (0 ਬਾਈਟ ਮੁਫ਼ਤ): ਡਾਟਾਬੇਸ WAL ਲੌਗ ਬਲੋਟ, ਖਰਾਬ ਬੀ-ਟ੍ਰੀ, ਅਤੇ ਜ਼ੀਰੋ-ਸਪੇਸ ਰਿਕਵਰੀ
• ਲੀਨਕਸ, ਮੈਕੋਸ, ਜਾਂ ਵਿੰਡੋਜ਼ 'ਤੇ ਦੁਰਘਟਨਾਤਮਕ rm -rf ਜਾਂ Shift+Delete: ਤੁਰੰਤ ਰੀਡ-ਓਨਲੀ ਰੀਮਾਉਂਟ ਅਤੇ ਇਨੋਡ ਕਾਰਵਿੰਗ
• ਵਰਚੁਅਲ ਮਸ਼ੀਨ VMDK, VHDX, ਅਤੇ qcow2 ਸਨੈਪਸ਼ਾਟ ਚੇਨ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਅਤੇ ਹਾਈਪਰਵਾਈਜ਼ਰ ਬਚਾਅ
• AWS ਕੁੰਜੀਆਂ, .env ਫਾਈਲ, ਜਾਂ ਜਨਤਕ GitHub ਰੈਪੋ ਲਈ ਪ੍ਰਾਈਵੇਟ SSH ਕੁੰਜੀ ਦੀ ਦੁਰਘਟਨਾਤਮਕ ਗਿੱਟ ਕਮਿਟ
• ਵੈੱਬ ਹੋਸਟਿੰਗ ਸੰਕਟ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਬੈਕਅੱਪ ਬਹਾਲੀ
• ਕੰਪਿਊਟਰ ਬੈਕਅੱਪ, 3-2-1 ਰਣਨੀਤੀ, ਅਤੇ ਆਫ਼ਤ ਰਿਕਵਰੀ
• ਦੇਸ਼ ਦੁਆਰਾ ਐਮਰਜੈਂਸੀ ਨੰਬਰ

ਸਰੋਤ ਅਤੇ ਅਧਿਕਾਰਤ ਮਾਰਗਦਰਸ਼ਨ¶

• ਕੁਬਰਨੇਟਸ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ (kubernetes.io / ਕਲਾਉਡ ਨੇਟਿਵ ਕੰਪਿਊਟਿੰਗ ਫਾਊਂਡੇਸ਼ਨ): ਸਟੋਰੇਜ ਆਬਜੈਕਟ ਇਨ ਯੂਜ਼ ਪ੍ਰੋਟੈਕਸ਼ਨ (kubernetes.io/pvc-protection ਫਾਈਨਲਾਈਜ਼ਰ), ਸਥਿਰ ਵਾਲੀਅਮ ਦਾ ਮੁੜ ਦਾਅਵਾ ਕਰਨਾ (Retain ਬਨਾਮ Delete), ਅਤੇ ਓਪਰੇਟਿੰਗ etcd ਕੁਬਰਨੇਟਸ ਲਈ ਕਲੱਸਟਰ (etcdctl snapshot restore)।
• ਡੌਕਰ ਇੰਕ. (docs.docker.com): ਡੌਕਰ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰਬੰਧਿਤ ਕਰੋ: ਵਾਲੀਅਮ, ਬਾਇੰਡ ਮਾਊਂਟ, overlay2 ਸਟੋਰੇਜ਼ ਡਰਾਈਵਰ ਆਰਕੀਟੈਕਚਰ, ਅਤੇ ਪ੍ਰੂਨ ਰੈਫਰੈਂਸ।
• ਲੀਨਕਸ ਕਰਨਲ ਸੰਗਠਨ (kernel.org): ਦ /proc ਫਾਇਲਸਿਸਟਮ(procfs ਦੁਆਰਾ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਰਿਕਵਰੀ ਖੋਲ੍ਹੋ /proc/<pid>/fd/) ਅਤੇ Ext4 ਜਰਨਲ ਨਿਰਧਾਰਨ।
• ext4magic ਪ੍ਰੋਜੈਕਟ ਦਸਤਾਵੇਜ਼ (ext4magic.sourceforge.net): Forensic Inode ਅਤੇ ਜਰਨਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਰਿਕਵਰੀ Ext3/Ext4 ਫਾਈਲਸਿਸਟਮ ਉੱਤੇ।
• ਨੈਸ਼ਨਲ ਇੰਸਟੀਚਿਊਟ ਆਫ਼ ਸਟੈਂਡਰਡਜ਼ ਐਂਡ ਟੈਕਨਾਲੋਜੀNIST) (ਸੰਯੁਕਤ ਰਾਜ): ਵਿਸ਼ੇਸ਼ ਪ੍ਰਕਾਸ਼ਨ 800-190: ਐਪਲੀਕੇਸ਼ਨ ਕੰਟੇਨਰ ਸੁਰੱਖਿਆ ਗਾਈਡ ਅਤੇ ਘਟਨਾ ਰਿਕਵਰੀ।