ਬੈਕਅੱਪ ਭਾਗ 4: zbackup, restic, borgbackup ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ

ਇਹ ਲੇਖ ਬੈਕਅੱਪ ਸੌਫਟਵੇਅਰ 'ਤੇ ਵਿਚਾਰ ਕਰੇਗਾ ਜੋ, ਡੇਟਾ ਸਟ੍ਰੀਮ ਨੂੰ ਵੱਖਰੇ ਹਿੱਸਿਆਂ (ਚੰਕਸ) ਵਿੱਚ ਤੋੜ ਕੇ, ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਉਂਦਾ ਹੈ।

ਰਿਪੋਜ਼ਟਰੀ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਹੋਰ ਸੰਕੁਚਿਤ ਅਤੇ ਏਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ - ਵਾਰ-ਵਾਰ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਦੌਰਾਨ - ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਅਜਿਹੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਬੈਕਅੱਪ ਕਾਪੀ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਭਾਗਾਂ ਦੀ ਇੱਕ ਨਾਮੀ ਲੜੀ ਹੁੰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਵੱਖ-ਵੱਖ ਹੈਸ਼ ਫੰਕਸ਼ਨਾਂ ਦੇ ਅਧਾਰ ਤੇ।

ਕਈ ਸਮਾਨ ਹੱਲ ਹਨ, ਮੈਂ 3 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਾਂਗਾ: zbackup, borgbackup ਅਤੇ restic.

ਅਨੁਮਾਨਤ ਨਤੀਜੇ

ਕਿਉਂਕਿ ਸਾਰੇ ਬਿਨੈਕਾਰਾਂ ਨੂੰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਆਕਾਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੋਵੇਗਾ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਇਸਦਾ ਆਕਾਰ ਪ੍ਰਵਾਨਿਤ ਵਿਧੀ ਅਨੁਸਾਰ 13 GB ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਘੱਟ - ਵਧੀਆ ਅਨੁਕੂਲਤਾ ਦੇ ਅਧੀਨ.

ਟਾਰ ਵਰਗੇ ਆਰਕਾਈਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ, ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਫਾਈਲਾਂ ਦੀਆਂ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਬਣਾਉਣ ਦੇ ਯੋਗ ਹੋਣਾ ਵੀ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ rsync ਅਤੇ sshfs ਵਰਗੇ ਵਾਧੂ ਸਾਧਨਾਂ ਦੇ ਬਿਨਾਂ ssh/sftp ਨਾਲ ਕੰਮ ਕਰਨਾ ਵੀ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ।

ਬੈਕਅੱਪ ਬਣਾਉਣ ਵੇਲੇ ਵਿਵਹਾਰ:

1. ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਆਕਾਰ ਤਬਦੀਲੀਆਂ ਦੇ ਆਕਾਰ ਦੇ ਬਰਾਬਰ ਜਾਂ ਘੱਟ ਹੋਵੇਗਾ।
2. ਕੰਪਰੈਸ਼ਨ ਅਤੇ/ਜਾਂ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਭਾਰੀ CPU ਲੋਡ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਜੇਕਰ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਸਰਵਰ 'ਤੇ ਆਰਕਾਈਵਿੰਗ ਅਤੇ/ਜਾਂ ਇਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ ਤਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨੈੱਟਵਰਕ ਅਤੇ ਡਿਸਕ ਲੋਡ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ।
3. ਜੇਕਰ ਰਿਪੋਜ਼ਟਰੀ ਖਰਾਬ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਨਵੇਂ ਬੈਕਅੱਪ ਬਣਾਉਣ ਵੇਲੇ ਅਤੇ ਰੀਸਟੋਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਦੇਰੀ ਨਾਲ ਗਲਤੀ ਹੋ ਸਕਦੀ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵਾਧੂ ਉਪਾਵਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਜਾਂ ਇਸਦੀ ਅਖੰਡਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਬਿਲਟ-ਇਨ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਟਾਰ ਨਾਲ ਕੰਮ ਕਰਨਾ ਇੱਕ ਸੰਦਰਭ ਮੁੱਲ ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਲੇਖਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਸੀ।

Zbackup ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

ਜ਼ੈੱਡਬੈਕਅਪ ਦੀ ਆਮ ਵਿਧੀ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਇਨਪੁਟ ਡੇਟਾ ਸਟ੍ਰੀਮ ਖੇਤਰਾਂ ਵਿੱਚ ਉਹੀ ਡੇਟਾ ਰੱਖਦਾ ਹੈ, ਫਿਰ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਅਤੇ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਹਰੇਕ ਖੇਤਰ ਨੂੰ ਸਿਰਫ ਇੱਕ ਵਾਰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹੋਏ।

ਡੀਡੁਪਲੀਕੇਸ਼ਨ ਮੌਜੂਦਾ ਡਾਟਾ ਬਲਾਕਾਂ ਦੇ ਵਿਰੁੱਧ ਬਾਈਟ-ਬਾਈ-ਬਾਈਟ ਮੈਚਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਸਲਾਈਡਿੰਗ ਵਿੰਡੋ ਦੇ ਨਾਲ ਇੱਕ 64-ਬਿੱਟ ਰਿੰਗ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ (ਇਸੇ ਤਰ੍ਹਾਂ ਕਿ rsync ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦਾ ਹੈ)।

ਮਲਟੀ-ਥ੍ਰੈੱਡਡ lzma ਅਤੇ lzo ਦੀ ਵਰਤੋਂ ਕੰਪਰੈਸ਼ਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਲਈ aes। ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਭਵਿੱਖ ਵਿੱਚ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਪੁਰਾਣੇ ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਸਮਰੱਥਾ ਹੈ।
ਪ੍ਰੋਗਰਾਮ ਘੱਟੋ-ਘੱਟ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ C++ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਲੇਖਕ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਯੂਨਿਕਸ-ਵੇਅ ਤੋਂ ਪ੍ਰੇਰਿਤ ਸੀ, ਇਸਲਈ ਪ੍ਰੋਗਰਾਮ ਬੈਕਅੱਪ ਬਣਾਉਣ ਵੇਲੇ stdin 'ਤੇ ਡੇਟਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਬਹਾਲ ਕਰਨ ਵੇਲੇ stdout 'ਤੇ ਸਮਾਨ ਡੇਟਾ ਸਟ੍ਰੀਮ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਆਪਣੇ ਖੁਦ ਦੇ ਬੈਕਅੱਪ ਹੱਲ ਲਿਖਣ ਵੇਲੇ zbackup ਨੂੰ ਇੱਕ ਬਹੁਤ ਵਧੀਆ "ਬਿਲਡਿੰਗ ਬਲਾਕ" ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਲੇਖ ਦੇ ਲੇਖਕ ਨੇ ਲਗਭਗ 2014 ਤੋਂ ਇਸ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਘਰੇਲੂ ਮਸ਼ੀਨਾਂ ਲਈ ਮੁੱਖ ਬੈਕਅੱਪ ਟੂਲ ਵਜੋਂ ਵਰਤਿਆ ਹੈ।

ਡੇਟਾ ਸਟ੍ਰੀਮ ਇੱਕ ਨਿਯਮਤ ਟਾਰ ਹੋਵੇਗੀ ਜਦੋਂ ਤੱਕ ਕਿ ਹੋਰ ਨਹੀਂ ਦੱਸਿਆ ਗਿਆ ਹੈ।

ਆਓ ਦੇਖੀਏ ਕਿ ਨਤੀਜੇ ਕੀ ਹਨ:

ਕੰਮ ਨੂੰ 2 ਵਿਕਲਪਾਂ ਵਿੱਚ ਚੈੱਕ ਕੀਤਾ ਗਿਆ ਸੀ:

1. ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ zbackup ਨੂੰ ਸਰੋਤ ਡੇਟਾ ਦੇ ਨਾਲ ਸਰਵਰ ਉੱਤੇ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਰਿਪੋਜ਼ਟਰੀ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਨੂੰ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਸਰਵਰ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
2. ਬੈਕਅੱਪ ਸਟੋਰੇਜ਼ ਸਰਵਰ 'ਤੇ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਬੈਕਅੱਪ ਸਟੋਰੇਜ਼ ਸਰਵਰ 'ਤੇ ssh ਰਾਹੀਂ zbackup ਨੂੰ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡੇਟਾ ਨੂੰ ਪਾਈਪ ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

ਪਹਿਲੇ ਵਿਕਲਪ ਦੇ ਨਤੀਜੇ ਇਸ ਪ੍ਰਕਾਰ ਸਨ: 43m11s - ਜਦੋਂ ਇੱਕ ਅਨਇਨਕ੍ਰਿਪਟਡ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ lzma ਕੰਪ੍ਰੈਸਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, 19m13s - ਜਦੋਂ ਕੰਪ੍ਰੈਸਰ ਨੂੰ lzo ਨਾਲ ਬਦਲਦੇ ਹੋ।

ਮੂਲ ਡੇਟਾ ਦੇ ਨਾਲ ਸਰਵਰ ਉੱਤੇ ਲੋਡ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸੀ (lzma ਦੇ ਨਾਲ ਇੱਕ ਉਦਾਹਰਨ ਦਿਖਾਈ ਗਈ ਹੈ; lzo ਦੇ ਨਾਲ ਲਗਭਗ ਇੱਕੋ ਤਸਵੀਰ ਸੀ, ਪਰ rsync ਦਾ ਸ਼ੇਅਰ ਸਮੇਂ ਦਾ ਇੱਕ ਚੌਥਾਈ ਸੀ):

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਜਿਹੀ ਬੈਕਅੱਪ ਪ੍ਰਕਿਰਿਆ ਸਿਰਫ ਮੁਕਾਬਲਤਨ ਦੁਰਲੱਭ ਅਤੇ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਲਈ ਢੁਕਵੀਂ ਹੈ. ਜ਼ੈੱਡਬੈਕਅਪ ਨੂੰ 1 ਥ੍ਰੈਡ ਤੱਕ ਸੀਮਿਤ ਕਰਨ ਦੀ ਵੀ ਬਹੁਤ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ CPU ਲੋਡ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਪ੍ਰੋਗਰਾਮ ਮਲਟੀਪਲ ਥਰਿੱਡਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਡਿਸਕ 'ਤੇ ਲੋਡ ਛੋਟਾ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਆਧੁਨਿਕ ssd-ਅਧਾਰਿਤ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ। ਤੁਸੀਂ ਰਿਪੋਜ਼ਟਰੀ ਡੇਟਾ ਨੂੰ ਰਿਮੋਟ ਸਰਵਰ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ; ਓਪਰੇਸ਼ਨ ਦੀ ਗਤੀ ਨਿਯਮਤ rsync ਨਾਲ ਤੁਲਨਾਯੋਗ ਹੈ ਅਤੇ ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਸਰਵਰ ਦੇ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਇਸ ਪਹੁੰਚ ਦਾ ਨੁਕਸਾਨ ਇੱਕ ਸਥਾਨਕ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਸਟੋਰੇਜ ਹੈ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਡੇਟਾ ਦੀ ਡੁਪਲੀਕੇਸ਼ਨ.

ਅਭਿਆਸ ਵਿੱਚ ਵਧੇਰੇ ਦਿਲਚਸਪ ਅਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲਾ ਦੂਜਾ ਵਿਕਲਪ ਹੈ, ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਸਰਵਰ 'ਤੇ ਸਿੱਧੇ zbackup ਨੂੰ ਚਲਾਉਣਾ।

ਪਹਿਲਾਂ, ਅਸੀਂ lzma ਕੰਪ੍ਰੈਸਰ ਨਾਲ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਓਪਰੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਾਂਗੇ:

ਹਰੇਕ ਟੈਸਟ ਦੇ ਚੱਲਣ ਦਾ ਸਮਾਂ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

39 ਐਮ 45 ਐੱਸ
40 ਐਮ 20 ਐੱਸ
40 ਐਮ 3 ਐੱਸ

7 ਐਮ 36 ਐੱਸ
8 ਐਮ 3 ਐੱਸ
7 ਐਮ 48 ਐੱਸ

15 ਐਮ 35 ਐੱਸ
15 ਐਮ 48 ਐੱਸ
15 ਐਮ 38 ਐੱਸ

ਜੇਕਰ ਤੁਸੀਂ ਏਈਐਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਨਤੀਜੇ ਕਾਫ਼ੀ ਨੇੜੇ ਹਨ:

ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਨਾਲ, ਉਸੇ ਡੇਟਾ 'ਤੇ ਓਪਰੇਟਿੰਗ ਸਮਾਂ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

43 ਐਮ 40 ਐੱਸ
44 ਐਮ 12 ਐੱਸ
44 ਐਮ 3 ਐੱਸ

8 ਐਮ 3 ਐੱਸ
8 ਐਮ 15 ਐੱਸ
8 ਐਮ 12 ਐੱਸ

15 ਐਮ 0 ਐੱਸ
15 ਐਮ 40 ਐੱਸ
15 ਐਮ 25 ਐੱਸ

ਜੇਕਰ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ lzo ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਪਰੈਸ਼ਨ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਕੰਮ ਦੇ ਘੰਟੇ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

18 ਐਮ 2 ਐੱਸ
18 ਐਮ 15 ਐੱਸ
18 ਐਮ 12 ਐੱਸ

5 ਐਮ 13 ਐੱਸ
5 ਐਮ 24 ਐੱਸ
5 ਐਮ 20 ਐੱਸ

8 ਐਮ 48 ਐੱਸ
9 ਐਮ 3 ਐੱਸ
8 ਐਮ 51 ਐੱਸ

ਨਤੀਜੇ ਵਜੋਂ ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਆਕਾਰ 13GB 'ਤੇ ਮੁਕਾਬਲਤਨ ਇੱਕੋ ਜਿਹਾ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੁਪਲੀਕੇਸ਼ਨ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਨਾਲ ਹੀ, ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਸੰਕੁਚਿਤ ਡੇਟਾ 'ਤੇ, lzo ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਇੱਕ ਧਿਆਨ ਦੇਣ ਯੋਗ ਪ੍ਰਭਾਵ ਮਿਲਦਾ ਹੈ; ਕੁੱਲ ਓਪਰੇਟਿੰਗ ਸਮੇਂ ਦੇ ਰੂਪ ਵਿੱਚ, zbackup ਡੁਪਲੀਸੀਟੀ/ਡੁਪਲੀਕੇਟੀ ਦੇ ਨੇੜੇ ਆਉਂਦਾ ਹੈ, ਪਰ librsync 'ਤੇ ਅਧਾਰਤ ਲੋਕਾਂ ਤੋਂ 2-5 ਗੁਣਾ ਪਿੱਛੇ ਰਹਿ ਜਾਂਦਾ ਹੈ।

ਫਾਇਦੇ ਸਪੱਸ਼ਟ ਹਨ - ਬੈਕਅੱਪ ਸਟੋਰੇਜ ਸਰਵਰ 'ਤੇ ਡਿਸਕ ਸਪੇਸ ਬਚਾਉਣਾ. ਰਿਪੋਜ਼ਟਰੀ ਚੈਕਿੰਗ ਟੂਲਸ ਲਈ, zbackup ਦਾ ਲੇਖਕ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ; ਇਹ ਇੱਕ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਡਿਸਕ ਐਰੇ ਜਾਂ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਪ੍ਰਭਾਵ, ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਪ੍ਰੋਜੈਕਟ ਲਗਭਗ 3 ਸਾਲਾਂ ਤੋਂ ਅਜੇ ਵੀ ਖੜ੍ਹਾ ਹੈ (ਆਖਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਬੇਨਤੀ ਲਗਭਗ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਸੀ, ਪਰ ਜਵਾਬ ਦੇ ਬਿਨਾਂ).

ਬੋਰਗਬੈਕਅੱਪ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ

Borgbackup ਚੁਬਾਰੇ ਦਾ ਇੱਕ ਫੋਰਕ ਹੈ, zbackup ਦੇ ਸਮਾਨ ਇੱਕ ਹੋਰ ਸਿਸਟਮ. python ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਇਸ ਵਿੱਚ zbackup ਵਰਗੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੀ ਸੂਚੀ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਇਲਾਵਾ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:

• ਫਿਊਜ਼ ਰਾਹੀਂ ਬੈਕਅੱਪ ਮਾਊਂਟ ਕਰੋ
• ਰਿਪੋਜ਼ਟਰੀ ਸਮੱਗਰੀ ਦੀ ਜਾਂਚ ਕਰੋ
• ਕਲਾਇੰਟ-ਸਰਵਰ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰੋ
• ਡੇਟਾ ਲਈ ਵੱਖ-ਵੱਖ ਕੰਪ੍ਰੈਸ਼ਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਨਾਲ ਹੀ ਇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਵੇਲੇ ਫਾਈਲ ਕਿਸਮ ਦਾ ਨਿਰਧਾਰਨ ਵੀ ਕਰੋ।
• 2 ਏਨਕ੍ਰਿਪਸ਼ਨ ਵਿਕਲਪ, aes ਅਤੇ ਬਲੇਕ
• ਲਈ ਬਿਲਟ-ਇਨ ਟੂਲ

ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਜਾਂਚ

borgbackup ਬੈਂਚਮਾਰਕ crud ssh://backup_server/repo/path local_dir

ਨਤੀਜੇ ਇਸ ਪ੍ਰਕਾਰ ਸਨ:

CZ-BIG 96.51 MB/s (10 100.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 9.21s)
RZ- MEDIUM 76.16 MB/s (1000 1.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 13.13s)
UZ- ਦਰਮਿਆਨਾ 331.27 MB/s (1000 1.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 3.02s)
DZ-ਮੀਡੀਅਮ 387.36 MB/s (1000 1.00 MB ਸਾਰੀਆਂ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 2.58s)
CR-ਮੀਡੀਅਮ 37.80 MB/s (1000 1.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 26.45s)
RR-ਮੀਡੀਅਮ 68.90 MB/s (1000 1.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 14.51s)
ਯੂਆਰ-ਮੀਡੀਅਮ 347.24 MB/s (1000 1.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 2.88s)
DR-ਮੀਡੀਅਮ 48.80 MB/s (1000 1.00 MB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB ਆਲ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB ਆਲ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB ਆਲ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB ਆਲ-ਜ਼ੀਰੋ ਫ਼ਾਈਲਾਂ: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 14.60)
RR-SMALL 31.27 MB/s (10000 10.00 kB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 3.20)
UR-ਛੋਟਾ 12.28 MB/s (10000 10.00 kB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 8.14)
DR-ਛੋਟਾ 18.78 MB/s (10000 10.00 kB ਬੇਤਰਤੀਬ ਫਾਈਲਾਂ: 5.32)

ਜਦੋਂ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੰਪਰੈਸ਼ਨ ਹਿਉਰਿਸਟਿਕਸ ਦੀ ਵਰਤੋਂ ਫਾਈਲ ਕਿਸਮ (ਕੰਪਰੈਸ਼ਨ ਆਟੋ) ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਵੇਗੀ, ਅਤੇ ਨਤੀਜੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਣਗੇ:

ਪਹਿਲਾਂ, ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਐਨਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

ਕੰਮ ਦੇ ਘੰਟੇ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

4 ਐਮ 6 ਐੱਸ
4 ਐਮ 10 ਐੱਸ
4 ਐਮ 5 ਐੱਸ

56s
58s
54s

1 ਐਮ 26 ਐੱਸ
1 ਐਮ 34 ਐੱਸ
1 ਐਮ 30 ਐੱਸ

ਜੇਕਰ ਤੁਸੀਂ ਰਿਪੋਜ਼ਟਰੀ ਅਧਿਕਾਰ (ਪ੍ਰਮਾਣਿਤ ਮੋਡ) ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਨਤੀਜੇ ਨੇੜੇ ਹੋਣਗੇ:

ਕੰਮ ਦੇ ਘੰਟੇ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

4 ਐਮ 11 ਐੱਸ
4 ਐਮ 20 ਐੱਸ
4 ਐਮ 12 ਐੱਸ

1 ਐਮ 0 ਐੱਸ
1 ਐਮ 3 ਐੱਸ
1 ਐਮ 2 ਐੱਸ

1 ਐਮ 30 ਐੱਸ
1 ਐਮ 34 ਐੱਸ
1 ਐਮ 31 ਐੱਸ

ਜਦੋਂ aes ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਨਤੀਜੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਗੜਦੇ ਨਹੀਂ ਸਨ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

4 ਐਮ 55 ਐੱਸ
5 ਐਮ 2 ਐੱਸ
4 ਐਮ 58 ਐੱਸ

1 ਐਮ 0 ਐੱਸ
1 ਐਮ 2 ਐੱਸ
1 ਐਮ 0 ਐੱਸ

1 ਐਮ 49 ਐੱਸ
1 ਐਮ 50 ਐੱਸ
1 ਐਮ 50 ਐੱਸ

ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਏਈਐਸ ਨੂੰ ਬਲੇਕ ਵਿੱਚ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਸਥਿਤੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਧਰ ਜਾਵੇਗੀ:

ਕੰਮ ਦੇ ਘੰਟੇ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

4 ਐਮ 33 ਐੱਸ
4 ਐਮ 43 ਐੱਸ
4 ਐਮ 40 ਐੱਸ

59s
1 ਐਮ 0 ਐੱਸ
1 ਐਮ 0 ਐੱਸ

1 ਐਮ 38 ਐੱਸ
1 ਐਮ 43 ਐੱਸ
1 ਐਮ 40 ਐੱਸ

ਜਿਵੇਂ ਕਿ ਜ਼ੈੱਡਬੈਕਅਪ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਆਕਾਰ 13GB ਸੀ ਅਤੇ ਥੋੜਾ ਘੱਟ, ਜਿਸਦੀ ਆਮ ਤੌਰ 'ਤੇ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਮੈਂ ਚੱਲ ਰਹੇ ਸਮੇਂ ਤੋਂ ਬਹੁਤ ਖੁਸ਼ ਸੀ; ਇਹ librsync 'ਤੇ ਅਧਾਰਤ ਹੱਲਾਂ ਨਾਲ ਤੁਲਨਾਯੋਗ ਹੈ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਆਪਕ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਮੈਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੁਆਰਾ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਯੋਗਤਾ ਤੋਂ ਵੀ ਖੁਸ਼ ਸੀ, ਜੋ ਕਿ ਆਟੋਮੈਟਿਕ ਮੋਡ ਵਿੱਚ ਬੋਰਗਬੈਕਅਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਬਹੁਤ ਗੰਭੀਰ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ। ਮੈਂ ਬੈਕਅੱਪ ਦੇ ਦੌਰਾਨ ਲੋਡ ਤੋਂ ਵੀ ਖੁਸ਼ ਸੀ: ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਬੋਰਗਬੈਕਅਪ 1 ਥ੍ਰੈਡ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ.

ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੋਈ ਖਾਸ ਨੁਕਸਾਨ ਨਹੀਂ ਸਨ.

ਆਰਾਮਦਾਇਕ ਟੈਸਟਿੰਗ

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਰੈਸਟਿਕ ਇੱਕ ਕਾਫ਼ੀ ਨਵਾਂ ਹੱਲ ਹੈ (ਪਹਿਲੇ 2 ਉਮੀਦਵਾਰ 2013 ਅਤੇ ਪੁਰਾਣੇ ਵਿੱਚ ਜਾਣੇ ਜਾਂਦੇ ਸਨ), ਇਸ ਵਿੱਚ ਕਾਫ਼ੀ ਚੰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ। ਗੋ ਵਿੱਚ ਲਿਖਿਆ।

ਜਦੋਂ zbackup ਨਾਲ ਤੁਲਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਇਸ ਤੋਂ ਇਲਾਵਾ ਦਿੰਦਾ ਹੈ:

• ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ (ਪੁਰਜ਼ਿਆਂ ਦੀ ਜਾਂਚ ਸਮੇਤ)।
• ਬੈਕਅਪ ਸਟੋਰ ਕਰਨ ਲਈ ਸਮਰਥਿਤ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਸੂਚੀ, ਅਤੇ ਨਾਲ ਹੀ ਕਲਾਉਡ ਹੱਲ ਲਈ rclone - rsync ਲਈ ਸਮਰਥਨ।
• ਇੱਕ ਦੂਜੇ ਨਾਲ 2 ਬੈਕਅੱਪ ਦੀ ਤੁਲਨਾ ਕਰਨਾ।
• ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਫਿਊਜ਼ ਰਾਹੀਂ ਮਾਊਂਟ ਕਰਨਾ।

ਆਮ ਤੌਰ 'ਤੇ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਸੂਚੀ ਬੋਰਗਬੈਕਅਪ ਦੇ ਕਾਫ਼ੀ ਨੇੜੇ ਹੈ, ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਵਧੇਰੇ, ਦੂਜਿਆਂ ਵਿੱਚ ਘੱਟ। ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਏਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਲਈ ਬੈਕਅੱਪ ਕਾਪੀਆਂ ਹਮੇਸ਼ਾ ਏਨਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ। ਆਓ ਅਭਿਆਸ ਵਿੱਚ ਵੇਖੀਏ ਕਿ ਇਸ ਸੌਫਟਵੇਅਰ ਵਿੱਚੋਂ ਕੀ ਨਿਚੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ:

ਨਤੀਜੇ ਇਸ ਪ੍ਰਕਾਰ ਸਨ:

ਕੰਮ ਦੇ ਘੰਟੇ:

1 ਲਾਂਚ ਕਰੋ
2 ਲਾਂਚ ਕਰੋ
3 ਲਾਂਚ ਕਰੋ

5 ਐਮ 25 ਐੱਸ
5 ਐਮ 50 ਐੱਸ
5 ਐਮ 38 ਐੱਸ

35s
38s
36s

1 ਐਮ 54 ਐੱਸ
2 ਐਮ 2 ਐੱਸ
1 ਐਮ 58 ਐੱਸ

ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨਤੀਜੇ ਵੀ rsync-ਅਧਾਰਿਤ ਹੱਲਾਂ ਨਾਲ ਤੁਲਨਾਯੋਗ ਹਨ ਅਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਬੋਰਗਬੈਕਅੱਪ ਦੇ ਬਹੁਤ ਨੇੜੇ ਹਨ, ਪਰ CPU ਲੋਡ ਵੱਧ ਹੈ (ਮਲਟੀਪਲ ਥ੍ਰੈਡ ਚੱਲ ਰਹੇ ਹਨ) ਅਤੇ ਆਰਾ ਟੁੱਥ।

ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਪ੍ਰੋਗਰਾਮ ਡਾਟਾ ਸਟੋਰੇਜ਼ ਸਰਵਰ 'ਤੇ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੁਆਰਾ ਸੀਮਿਤ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ rsync ਨਾਲ ਹੋਇਆ ਸੀ। ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਆਕਾਰ 13GB ਸੀ, ਜਿਵੇਂ ਕਿ zbackup ਜਾਂ borgbackup, ਇਸ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੋਈ ਸਪੱਸ਼ਟ ਨੁਕਸਾਨ ਨਹੀਂ ਸਨ।

Результаты

ਵਾਸਤਵ ਵਿੱਚ, ਸਾਰੇ ਉਮੀਦਵਾਰਾਂ ਨੇ ਇੱਕੋ ਜਿਹੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕੀਤੇ, ਪਰ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ 'ਤੇ। ਬੋਰਗਬੈਕਅਪ ਨੇ ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ, ਆਰਾਮਦਾਇਕ ਥੋੜਾ ਹੌਲੀ ਸੀ, zbackup ਸ਼ਾਇਦ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੈ,
ਅਤੇ ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਵਿੱਚ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬੋਰਗਬੈਕਅਪ ਜਾਂ ਰੈਸਟਿਕ ਵਿੱਚ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।

ਸਿੱਟਾ

ਸਭ ਤੋਂ ਹੋਨਹਾਰ ਹੱਲ ਅਰਾਮਦਾਇਕ ਜਾਪਦਾ ਹੈ, ਕਿਉਂਕਿ ... ਇਹ ਉਹ ਹੈ ਜਿਸ ਕੋਲ ਸੰਚਾਲਨ ਗਤੀ ਲਈ ਸਮਰੱਥਾਵਾਂ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਅਨੁਪਾਤ ਹੈ, ਪਰ ਆਓ ਇਸ ਸਮੇਂ ਲਈ ਆਮ ਸਿੱਟਿਆਂ 'ਤੇ ਕਾਹਲੀ ਨਾ ਕਰੀਏ।

ਬੋਰਗਬੈਕਅਪ ਅਸਲ ਵਿੱਚ ਕੋਈ ਮਾੜਾ ਨਹੀਂ ਹੈ, ਪਰ zbackup ਸ਼ਾਇਦ ਬਿਹਤਰ ਬਦਲਿਆ ਗਿਆ ਹੈ। ਇਹ ਸੱਚ ਹੈ ਕਿ 3-2-1 ਨਿਯਮ ਦੇ ਕੰਮ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ zbackup ਦੀ ਵਰਤੋਂ ਅਜੇ ਵੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, (lib)rsync-ਅਧਾਰਿਤ ਬੈਕਅੱਪ ਸਹੂਲਤਾਂ ਤੋਂ ਇਲਾਵਾ।

ਘੋਸ਼ਣਾ

ਬੈਕਅੱਪ, ਭਾਗ 1: ਬੈਕਅੱਪ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ, ਤਰੀਕਿਆਂ, ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ
ਬੈਕਅੱਪ ਭਾਗ 2: rsync-ਅਧਾਰਿਤ ਬੈਕਅੱਪ ਟੂਲਸ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ
ਬੈਕਅੱਪ ਭਾਗ 3: ਡੁਪਲੀਸੀਟੀ, ਡੁਪਲੀਸੀਟੀ ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ
ਬੈਕਅੱਪ ਭਾਗ 4: zbackup, restic, borgbackup ਦੀ ਸਮੀਖਿਆ ਅਤੇ ਜਾਂਚ ਕਰਨਾ
ਬੈਕਅੱਪ ਭਾਗ 5: ਲੀਨਕਸ ਲਈ ਬੈਕੂਲਾ ਅਤੇ ਵੀਮ ਬੈਕਅੱਪ ਦੀ ਜਾਂਚ
ਬੈਕਅੱਪ ਭਾਗ 6: ਬੈਕਅੱਪ ਟੂਲਸ ਦੀ ਤੁਲਨਾ ਕਰਨਾ
ਬੈਕਅੱਪ ਭਾਗ 7: ਸਿੱਟਾ

ਵੱਲੋਂ ਪੋਸਟ ਕੀਤਾ ਗਿਆ: ਪਾਵੇਲ ਡੇਮਕੋਵਿਚ

ਸਰੋਤ: www.habr.com