ਕੰਟੇਨਰ ਦਾ ਜਾਂ ਉਸ ਦੀਆਂ ਫਾਈਲਾਂ ਦਾ ਬੈਕਅੱਪ? ਬਹਾਲੀ ਦੀ ਸ਼ਕਲ ਨਾਲ ਫੈਸਲਾ ਕਰੋ
ਇਮੇਜ ਅਤੇ ਫਾਈਲ-ਪੱਧਰੀ ਬੈਕਅੱਪ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਬਹਾਲ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੀਆਂ ਚਾਬੀਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਸੰਭਾਲੀ ਵਸਤੂ ਨੂੰ ਉਸ ਬਹਾਲੀ ਨਾਲ ਮਿਲਾਓ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਚਾਹੀਦੀ ਹੈ।
ਤੁਸੀਂ ਇੱਕ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਕੰਟੇਨਰ ਦਾ ਬੈਕਅੱਪ ਇੱਕੋ ਵਸਤੂ ਵਜੋਂ ਲੈ ਸਕਦੇ ਹੋ, ਜਾਂ ਉਸਨੂੰ ਮਾਊਂਟ ਕਰਕੇ ਅੰਦਰਲੀਆਂ ਫਾਈਲਾਂ ਦਾ ਬੈਕਅੱਪ ਲੈ ਸਕਦੇ ਹੋ। ਦੋਵੇਂ VPN ਰਾਹੀਂ ਆਸਾਨੀ ਨਾਲ ਲੰਘਦੇ ਹਨ, ਅਤੇ ਸਮਾਨਤਾ ਉੱਥੇ ਹੀ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਉਹ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਬਹਾਲ ਕਰਦੇ ਹਨ, ਵੱਖਰੀਆਂ ਚਾਬੀਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਵੱਖਰੀ ਥਾਂ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਡੇਟਾ ਵਾਪਸ ਚਾਹੀਦਾ ਹੋਣ ਵੇਲੇ ਵੱਖਰੇ ਢੰਗਾਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਪਹਿਲਾਂ ਬਹਾਲੀ ਦੀ ਵਸਤੂ ਚੁਣੋ, ਫਿਰ ਆਵਾਜਾਈ, ਫਿਰ ਸੰਭਾਲੀ ਕਾਪੀ ਦਾ ਐਨਕ੍ਰਿਪਸ਼ਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਚੈੱਕਲਿਸਟ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਕਿਉਂਕਿ ਲਗਭਗ ਹਰ ਬੈਕਅੱਪ ਵਿਵਾਦ ਅਸਲ ਵਿੱਚ ਇਸ ਗੱਲ 'ਤੇ ਮਤਭੇਦ ਹੈ ਕਿ ਇਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਫੈਸਲਾ ਪਹਿਲਾਂ ਲਿਆ ਗਿਆ।
ਦੋ ਵਸਤੂਆਂ, ਦੋ ਬਹਾਲੀ ਸ਼ਕਲਾਂ
ਇਮੇਜ-ਪੱਧਰੀ ਬੈਕਅੱਪ ਕੰਟੇਨਰ ਬਹਾਲ ਕਰਦਾ ਹੈ: ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਵੌਲਿਊਮ ਵਾਪਸ ਮਿਲਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਖੋਲ੍ਹਣ ਲਈ ਅਜੇ ਵੀ ਉਸਦੀ ਬਹਾਲੀ ਸਮੱਗਰੀ ਚਾਹੀਦੀ ਹੈ। ਫਾਈਲ-ਪੱਧਰੀ ਬੈਕਅੱਪ ਫਾਈਲਾਂ ਅਤੇ ਡਾਇਰੈਕਟਰੀ-ਦਰੱਖਤ ਬਹਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੀ ਰੱਖਿਆ ਕਰਨ ਵਾਲਾ ਜੋ ਵੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਹੈ ਉਹ ਬੈਕਅੱਪ ਭੰਡਾਰ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਮੂਲ ਕੰਟੇਨਰ ਦੀ ਨਹੀਂ। ਦੂਰ ਦੇ ਫੋਲਡਰ ਵਿੱਚ ਸਾਧਾਰਨ ਕਾਪੀ ਤੀਜਾ ਮਾਮਲਾ ਹੈ, ਅਤੇ ਉਹ ਉਸ ਫੋਲਡਰ ਕੋਲ ਸੰਜੋਗ ਨਾਲ ਜੋ ਸੁਰੱਖਿਆ ਹੈ ਉਹ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੀ ਹੈ।
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
ਵਿਚਕਾਰਲੀ ਕਤਾਰ ਉਹੀ ਹੈ ਜੋ ਲੋਕ ਗਲਤ ਪੜ੍ਹਦੇ ਹਨ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੰਗਾ ਡਿਜ਼ਾਈਨ ਹੋ ਸਕਦਾ ਹੈ: ਬੈਕਅੱਪ ਪ੍ਰੋਗਰਾਮ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਟੈਕਸਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ, ਪ੍ਰਮਾਣਿਤ ਭੰਡਾਰ ਲਿਖਦਾ ਹੈ। ਫਿਰ ਸੁਰੱਖਿਆ ਉਸ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਉਸਦੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ 'ਤੇ ਟਿਕਦੀ ਹੈ, ਮੂਲ ਕੰਟੇਨਰ ਦੇ ਪਾਸਵਰਡ 'ਤੇ ਨਹੀਂ, ਅਤੇ ਦੋਹਾਂ ਨੂੰ ਇੱਕੋ ਨਿਯੰਤਰਣ ਵਜੋਂ ਨਹੀਂ ਦੱਸਣਾ ਚਾਹੀਦਾ।
ਜਾਂਚ 1: ਬਹਾਲੀ ਨੇ ਕੀ ਮੁੜ-ਉਸਾਰਨਾ ਹੈ?
ਸਵਾਲ ਬੈਕਅੱਪ ਦੇ ਨਹੀਂ, ਬਹਾਲੀ ਦੇ ਰੂਪ ਵਿੱਚ ਪੁੱਛੋ। ਜੇ ਲੋੜ “ਇਸ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਹੋਸਟ 'ਤੇ ਵਾਪਸ ਲਿਆਓ” ਹੈ, ਤਾਂ ਇਮੇਜ ਅਤੇ ਉਸਦੀ ਬਹਾਲੀ ਸਮੱਗਰੀ ਸੁਸੰਗਤ ਜਵਾਬ ਹੈ। ਜੇ ਲੋੜ “ਮਾਰਚ ਦੀ ਵਿੱਤੀ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਾਪਸ ਲਿਆਓ” ਹੈ, ਤਾਂ ਇੱਕ ਫਾਈਲ ਕੱਢਣ ਲਈ ਕਈ ਗੀਗਾਬਾਈਟ ਦਾ ਇਮੇਜ ਬਹਾਲ ਕਰਨਾ ਮਹਿੰਗਾ ਜਵਾਬ ਹੈ। ਦੋਵੇਂ ਜਾਇਜ਼ ਬਹਾਲੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਇੱਕ-ਦੂਜੇ ਦੀ ਥਾਂ ਲੈ ਸਕਣ ਵਾਲੇ ਬਜਟ ਨਹੀਂ ਹਨ। ਸਿਰਫ਼ ਇੱਕ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਯੋਜਨਾ ਦੀ ਅੰਤ ਵਿੱਚ ਦੂਜੀ ਨਾਲ ਜਾਂਚ ਹੋਵੇਗੀ।
ਬਹਾਲੀ ਦਾ ਟੀਚਾ ਯੋਜਨਾ ਵਿੱਚ ਲਿਖੋ: ਪੂਰਾ ਵੌਲਿਊਮ, ਡਾਇਰੈਕਟਰੀ-ਦਰੱਖਤ, ਜਾਂ ਵੱਖਰੀਆਂ ਫਾਈਲਾਂ। ਫਿਰ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜਾ ਮੈਟਾਡੇਟਾ ਉਹਨਾਂ ਨਾਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਮਾਲਕੀ, ਇਜਾਜ਼ਤਾਂ, ਵਿਸਤ੍ਰਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਸਮਾਂ-ਛਾਪ ਫਾਈਲ-ਪੱਧਰੀ ਬਹਾਲੀ ਦਾ ਹਿੱਸਾ ਹਨ ਅਤੇ ਜਾਂਚ ਵੇਲੇ ਕਾਫ਼ੀ ਲੱਗਣ ਵਾਲੇ ਕਾਪੀ-ਆਧਾਰਿਤ ਕੰਮ-ਪ੍ਰਵਾਹਾਂ ਵਿੱਚ ਅਕਸਰ ਗੁਆਚ ਜਾਂਦੇ ਹਨ।
ਇਹ ਵੀ ਤੈਅ ਕਰੋ ਕਿ ਬਹਾਲੀ ਕੌਣ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਆਪਰੇਟਰ ਮਾਊਂਟ ਕਰ ਸਕਣ ਵਾਲਾ ਫਾਈਲ-ਪੱਧਰੀ ਭੰਡਾਰ, ਉਸ ਇਮੇਜ ਤੋਂ ਵੱਖਰਾ ਪਹੁੰਚ-ਮਾਡਲ ਹੈ ਜਿਸ ਲਈ ਚਾਬੀ ਧਾਰਕ ਦੀ ਹਾਜ਼ਰੀ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ ਬਿਹਤਰ ਨਹੀਂ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਚੋਣ ਜਾਣਬੁੱਝ ਕੇ ਅਤੇ ਲਿਖਤੀ ਹੋਵੇ।
ਜਾਂਚ 2: ਸੰਭਾਲੀ ਕਾਪੀ ਦੀ ਰੱਖਿਆ ਕੀ ਕਰਦਾ ਹੈ?
VPN ਆਵਾਜਾਈ ਦੇ ਇੱਕ ਹਿੱਸੇ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਤਬਾਦਲਾ ਮੁਕੰਮਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸੰਭਾਲੀ ਕਾਪੀ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ “ਇਹ ਸੁਰੰਗ ਵਿੱਚੋਂ ਲੰਘਿਆ” ਬੈਕਅੱਪ ਆਪਰੇਟਰ ਦੀ ਤੁਹਾਡਾ ਡੇਟਾ ਪੜ੍ਹਨ ਦੀ ਸਮਰੱਥਾ ਬਾਰੇ ਬਿਆਨ ਨਹੀਂ ਹੈ। ਜੇ ਦੂਰ ਦਾ ਪਾਸਾ ਕੋਈ ਹੋਰ ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਉਹ ਕੀ ਪੜ੍ਹ ਸਕਦੇ ਹਨ, ਇਹ ਨਹੀਂ ਕਿ ਲਿੰਕ ਐਨਕ੍ਰਿਪਟ ਸੀ ਜਾਂ ਨਹੀਂ।
ਇਮੇਜ ਲਈ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕੰਟੇਨਰ ਦੀ ਚਾਬੀ ਸਮੱਗਰੀ ਨੂੰ ਇਮੇਜ ਤੋਂ ਵੱਖਰਿਆਂ ਸੁਰੱਖਿਅਤ ਕਰਨਾ। ਹੈਡਰ ਗੁਆਉਣਾ ਵੌਲਿਊਮ ਗੁਆਉਣਾ ਹੈ, ਇਸ ਲਈ ਹੈਡਰ ਦਾ ਬੈਕਅੱਪ ਉੱਥੇ ਲਵੋ ਜਿੱਥੇ ਇਮੇਜ ਨਹੀਂ ਹੈ:
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20ਫਾਈਲ-ਪੱਧਰੀ ਭੰਡਾਰ ਲਈ, ਜਾਂਚੋ ਕਿ ਸਾਧਨ ਸਮੱਗਰੀ ਅਤੇ ਮੈਟਾਡੇਟਾ ਨੂੰ ਹੋਸਟ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਐਨਕ੍ਰਿਪਟ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪਤਾ ਕਰੋ ਕਿ ਚਾਬੀਆਂ ਕਿਸ ਕੋਲ ਹਨ। Restic ਦੀ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਸਪੱਸ਼ਟ ਕਹਿੰਦੀ ਹੈ ਕਿ ਇਹ ਭਰੋਸੇਯੋਗ ਸਰੋਤ-ਹੋਸਟ ਮੰਨਦੀ ਹੈ ਅਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਭੰਡਾਰ ਤੱਕ ਪਹੁੰਚ ਵਾਲੇ ਨੂੰ ਬੈਕਅੱਪ ਮਿਟਾਉਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦੀ। ਦੋਵੇਂ ਚੇਤਾਵਨੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ: ਭੰਡਾਰ ਗੁਪਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਨਸ਼ਟ ਹੋ ਸਕਦਾ ਹੈ।
ਜਾਂਚ 3: ਕੀ ਕਾਪੀ ਸੁਸੰਗਤ ਹੈ?
ਜੋ ਬੈਕਅੱਪ ਬਦਲਦੀ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਉਹ ਕਾਪੀ ਹੈ, ਬਹਾਲੀ-ਬਿੰਦੂ ਨਹੀਂ। ਇਮੇਜ ਲਈ ਵੌਲਿਊਮ ਸਾਧਨ ਦੀ ਸਮਰਥਿਤ ਵਿਧੀ ਨਾਲ ਸਥਿਰ ਸਨੈਪਸ਼ਾਟ ਲਵੋ, ਜਿਸਦਾ ਆਮ ਅਰਥ ਸਨੈਪਸ਼ਾਟ ਕਾਰਵਾਈ ਜਾਂ ਅਨਮਾਊਂਟ ਹੈ, ਵੱਡੀ ਫਾਈਲ ਬਦਲਦਿਆਂ ਪੜ੍ਹਨਾ ਨਹੀਂ:
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyਮਾਊਂਟ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਲਈ ਸਰਗਰਮ ਡੇਟਾਬੇਸ ਅਤੇ ਹੋਰ ਤਾਲਮੇਲ ਵਾਲੇ ਡੇਟਾ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਮਰਥਿਤ ਸੁਸੰਗਤਤਾ-ਕਾਰਵਾਈ ਵਰਤੋ। ਫਾਈਲ ਸਿਸਟਮ-ਪੱਧਰੀ ਕਾਪੀ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ-ਸੁਸੰਗਤ ਬਹਾਲੀ-ਬਿੰਦੂ ਵੱਖਰੇ ਵਰਣਨ ਹਨ, ਅਤੇ ਫ਼ਰਕ ਬਹਾਲ ਕੀਤੀ ਕਾਪੀ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ 'ਤੇ ਹੀ ਦਿਸਦਾ ਹੈ।
ਬਹਾਲੀ ਸਮੱਗਰੀ ਨੂੰ ਸੁਤੰਤਰ ਸੁਰੱਖਿਅਤ ਮਾਰਗ 'ਤੇ ਰੱਖੋ। ਮੂਲ ਮਸ਼ੀਨ ਗੁਆਉਣ ਨਾਲ ਉਸਦਾ ਬੈਕਅੱਪ ਖੋਲ੍ਹਣ ਵਾਲੇ ਇੱਕੋ-ਇੱਕ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਵੀ ਕਦੇ ਨਹੀਂ ਗੁਆਉਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਚਾਬੀ-ਫਾਈਲ ਉਸ ਵੌਲਿਊਮ 'ਤੇ ਹੋਣ ਸਮੇਂ ਬਿਲਕੁਲ ਇਹੀ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਬੈਕਅੱਪ ਲਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਸ ਵੱਖਰਾਅ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਪਰਖੋ: ਅਜਿਹੇ ਹੋਸਟ 'ਤੇ ਬਹਾਲ ਕਰੋ ਜਿਸਨੇ ਮੂਲ ਕਦੇ ਨਹੀਂ ਵੇਖਿਆ, ਸਿਰਫ਼ ਉਹੀ ਵਰਤ ਕੇ ਜੋ ਯੋਜਨਾ ਕਹਿੰਦੀ ਹੈ ਉਪਲਬਧ ਹੈ।
ਜਾਂਚ 4: ਕੀ ਇਸ ਵਸਤੂ ਲਈ ਤਬਦੀਲੀ-ਖੋਜ ਲਾਗੂ ਹੁੰਦੀ ਹੈ?
ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਕੰਟੇਨਰ ਬਹੁਤੇ ਤਬਾਦਲਾ ਸਾਧਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੀ ਅਪਾਰਦਰਸ਼ੀ ਫਾਈਲ ਵਾਂਗ ਦਿਸਦਾ ਹੈ, ਇਸ ਲਈ ਸਪਸ਼ਟ ਟੈਕਸਟ ਵਿੱਚ ਛੋਟੀ ਤਬਦੀਲੀ ਸਾਧਨ ਅਤੇ ਫਾਰਮੈਟ ਅਨੁਸਾਰ ਵੱਡੀ ਮੁੜ-ਪੜ੍ਹਾਈ ਜਾਂ ਪੂਰੀ ਮੁੜ-ਅੱਪਲੋਡ ਕਰ ਸਕਦੀ ਹੈ। restic ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ਿਤ ਬਦਲਦੇ ਆਕਾਰ ਦੀ ਚੰਕਿੰਗ ਅਤੇ ਡੁਪਲੀਕੇਟ ਹਟਾਉਣਾ ਇਹ ਘਟਾ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਉਸ ਸਾਧਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਕੰਟੇਨਰਾਂ ਦੀ ਨਹੀਂ।
ਮੰਨਣ ਦੀ ਥਾਂ ਮਾਪੋ। ਛੋਟੀ, ਬੇਨੁਕਸਾਨ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਦੌੜ ਦੀ ਦੂਜੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਤਬਾਦਲਾ ਕੀਤੇ ਬਾਈਟ ਅਤੇ ਬੀਤਿਆ ਸਮਾਂ ਦੋਵੇਂ ਦਰਜ ਕਰੋ। ਪ੍ਰਯੋਗ ਕਰਦਿਆਂ ਜਾਣਿਆ-ਚੰਗਾ ਬੈਕਅੱਪ ਰੱਖੋ, ਤਾਂ ਜੋ ਇੱਕ ਜਾਂਚ ਤੁਹਾਡਾ ਇੱਕੋ-ਇੱਕ ਬਹਾਲੀ-ਬਿੰਦੂ ਖ਼ਤਮ ਨਾ ਕਰ ਦੇਵੇ।
ਫਿਰ ਚੈੱਕਲਿਸਟ ਨੂੰ ਉਸ ਇੱਕੋ-ਇੱਕ ਜਾਂਚ ਨਾਲ ਪੂਰਾ ਕਰੋ ਜੋ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ: ਮੂਲ ਮਸ਼ੀਨ ਤੋਂ ਬਿਨਾਂ ਬਹਾਲੀ। ਬਹਾਲ ਕੀਤਾ ਕੰਟੇਨਰ ਖੋਲ੍ਹੋ, ਜਾਂ ਚੁਣੀਆਂ ਫਾਈਲਾਂ ਉਹਨਾਂ ਦੇ ਮੈਟਾਡੇਟਾ ਸਮੇਤ ਬਹਾਲ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਵਰਤੋਂਕਾਰ ਨਤੀਜਾ ਵਰਤ ਸਕਦਾ ਹੈ। ਉਸ ਜਾਂਚ ਦਾ ਜਵਾਬ ਨਾ ਦੇ ਸਕਣ ਵਾਲਾ ਤੇਜ਼, ਚੰਗੀ ਤਰ੍ਹਾਂ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਤਬਾਦਲਾ ਤੁਹਾਡੇ ਡੇਟਾ ਦੀ ਕਾਪੀ ਹੈ, ਉਸਦਾ ਬੈਕਅੱਪ ਨਹੀਂ।