VPN ਰਾਹੀਂ rsync: ਟੁੱਟੇ ਟ੍ਰਾਂਸਫਰ ਦੀ ਮੁੜ-ਵਰਤੋਂ ਕਰਨ ਵਾਲੀ ਮੁੜ ਕੋਸ਼ਿਸ਼

ਬਾਰਾਂ ਗੀਗਾਬਾਈਟ ਦੇ ਆਰਕਾਈਵ ਦੇ ਚਾਰ ਗੀਗਾਬਾਈਟ ’ਤੇ ਤੁਹਾਡਾ ਅੱਪਲੋਡ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਡਾਊਨਲੋਡ ਮੈਨੇਜਰਾਂ ਤੋਂ ਸਿੱਖੀ ਆਦਤ ਕਹਿੰਦੀ ਹੈ ਕਿ ਮੁੜ ਸ਼ੁਰੂ ਦਬਾਓ। rsync TCP ਸਟ੍ਰੀਮ ਮੁੜ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਉਹ ਸਟ੍ਰੀਮ ਟਨਲ ਦੇ ਆਖਰੀ ਮੁੜ-ਪ੍ਰਸਾਰਣ ਨਾਲ ਚਲੀ ਗਈ। ਜੋ ਇਹ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਹੈ ਪਹਿਲਾਂ ਹੀ ਮਿਲੇ ਬਾਈਟ ਰੱਖਣਾ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਆਧਾਰ ਬਣਾਉਣਾ, ਜੋ ਵੱਖਰੇ ਨਿਯਮ-ਸੈੱਟ ਵਾਲਾ ਵੱਖਰਾ ਤੰਤਰ ਹੈ। ਤੁਸੀਂ ਜੋ ਫਲੈਗ ਚੁਣਦੇ ਹੋ ਉਹ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਮੁੜ-ਵਰਤੋਂ ਹੋਵੇਗੀ ਜਾਂ ਨਹੀਂ।

ਮੁੜ ਕੋਸ਼ਿਸ਼ ਹਾਲਤ ਮੁੜ ਬਣਾਉਂਦੀ ਹੈ, ਸਟ੍ਰੀਮ ਮੁੜ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦੀ

ਜਦੋਂ SSH ਸੈਸ਼ਨ ਡਿੱਗਦਾ ਹੈ, ਦੂਰਲੇ ਸਿਰੇ ’ਤੇ ਸਿਰਫ਼ ਉਹੀ ਬਚਦਾ ਹੈ ਜੋ ਡਿਸਕ ’ਤੇ ਲਿਖਿਆ ਜਾ ਸਕਿਆ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਮੁੜ ਜੁੜਨ ਲਈ ਸੈਸ਼ਨ ਟੋਕਨ ਨਹੀਂ ਹੈ ਅਤੇ ਮੁੜ ਚਲਾਉਣ ਲਈ ਕ੍ਰਮ ਨੰਬਰ ਨਹੀਂ ਹੈ। ਅਗਲੀ ਵਾਰ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਦਾ ਹੈ, ਸਰੋਤ ਮੁੜ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੀ ਹੈ।

ਉਹੀ ਆਖਰੀ ਸਵਾਲ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਸ਼ਕ ਫਾਈਲ ਰੱਖਣਾ ਕਿਉਂ ਢੁੱਕਦਾ ਹੈ। ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਕਾਪੀ rsync ਨੂੰ ਤੁਲਨਾ ਲਈ ਕੁਝ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਐਲਗੋਰਿਦਮ ਸਿਰਫ਼ ਉਹ ਫ਼ਰਕ ਭੇਜਦਾ ਹੈ ਜੋ ਉਹ ਪਛਾਣ ਸਕਦਾ ਹੈ। ਇਹ ਅਜੇ ਵੀ ਮੈਟਾਡੇਟਾ ਦਾ ਨਵਾਂ ਟ੍ਰਾਂਸਫਰ ਅਤੇ ਸਰੋਤ ਉੱਤੇ ਨਵੀਂ ਲਾਂਘਾ ਹੈ, ਇਸ ਲਈ ਬਚਿਆ ਸਮਾਂ ਇਸ ਗੱਲ ਦੇ ਅਨੁਪਾਤ ਵਿੱਚ ਹੈ ਕਿ ਫਾਈਲ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਮਿਲਦਾ ਹੈ, ਇਸ ਗੱਲ ਦੇ ਨਹੀਂ ਕਿ ਪਿਛਲਾ ਕਨੈਕਸ਼ਨ ਕਿੰਨੀ ਦੂਰ ਗਿਆ ਸੀ। ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਨੇ ਕੁਝ ਨਹੀਂ ਰੱਖਿਆ, ਤਾਂ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਪੂਰੀ ਕਾਪੀ ਹੈ, ਪਹਿਲੇ ਨੇ ਕਿੰਨੇ ਗੀਗਾਬਾਈਟ ਸਰਕਾਏ ਹੋਣ।

ਤੈਅ ਕਰੋ ਕਿ ਮੁੜ-ਵਰਤੋਂ ਯੋਗ ਟੁਕੜਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ

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

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

ਮੰਜ਼ਿਲ ’ਤੇ ਵੀ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਅੰਸ਼ਕ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਟੁਕੜੇ ਲਈ ਕਾਫ਼ੀ ਥਾਂ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਵਾਲੀਅਮ ਨੂੰ ਪੂਰੀ ਫਾਈਲ ਲਈ ਵੀ ਕਾਫ਼ੀ ਥਾਂ ਚਾਹੀਦੀ ਹੈ। ਟ੍ਰਾਂਸਫਰ ਦੇ ਵਿਚਕਾਰ ਟਾਰਗਿਟ ਵਾਲੀਅਮ ਭਰ ਜਾਣ ਨਾਲ ਅਜਿਹੀ ਅਸਫਲਤਾ ਹੁੰਦੀ ਹੈ ਜੋ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਵਰਗੀ ਲੱਗਦੀ ਹੈ ਪਰ ਹੈ ਨਹੀਂ, ਅਤੇ ਇਹ ਰੱਖਿਆ ਟੁਕੜਾ ਕੱਟਿਆ ਹੋਇਆ ਛੱਡ ਸਕਦੀ ਹੈ। ਦੌੜ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਖਾਲੀ ਥਾਂ ਜਾਂਚੋ, ਅਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ। ਉਸੇ SSH ਮਾਰਗ ’ਤੇ df -h ਨਾਲ ਕੁਝ ਸਕਿੰਟ ਯੋਜਨਾ ਦੀ ਸਭ ਤੋਂ ਸਸਤੀ ਸੰਭਵ ਪਰਖ ਹੈ।

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

ਉਹੀ ਕਾਪੀ ਚਲਾਓ, ਵਧੇਰੇ ਚਤੁਰ ਨਹੀਂ

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

ਡੈਲਟਾ ਵਿਵਹਾਰ ਦੀ ਆਸ ਰੱਖਦਿਆਂ --whole-file ਨਾ ਜੋੜੋ। ਉਹ ਵਿਕਲਪ rsync ਨੂੰ ਰੋਲਿੰਗ-ਚੈਕਸਮ ਤੁਲਨਾ ਤੋਂ ਬਿਨਾਂ ਪੂਰੀ ਫਾਈਲ ਦੀ ਕਾਪੀ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਜੋ ਤੇਜ਼ ਸਥਾਨਕ ਲਿੰਕ ’ਤੇ ਵਾਜਬ ਚੋਣ ਹੈ ਅਤੇ ਅਸਫਲ ਲੰਮੀ ਦੂਰੀ ਦੇ ਅੱਪਲੋਡ ਤੋਂ ਬਾਅਦ ਬਿਲਕੁਲ ਗਲਤ। --inplace ਵੀ ਕਹਾਣੀ ਬਦਲਦਾ ਹੈ: ਇਹ ਸਿੱਧਾ ਮੰਜ਼ਿਲ ਫਾਈਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਇਸ ਲਈ ਰੁਕਾਵਟ ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ ਸਮੱਗਰੀ ਮਿਲਾਉਂਦੀ ਫਾਈਲ ਛੱਡਦੀ ਹੈ, ਪਿੱਛੇ ਹਟਣ ਲਈ ਵੱਖਰਾ ਟੁਕੜਾ ਨਹੀਂ ਬਚਦਾ।

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

ਵਸਤੂ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸਵੀਕਾਰ ਕਰੋ

ਪਹਿਲਾਂ ਨਿਕਾਸ ਹਾਲਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਗਲਤੀਆਂ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਆਕਾਰ ਜਾਂਚ ਜ਼ਿਆਦਾਤਰ ਕੱਟੇ ਟ੍ਰਾਂਸਫਰ ਫੜਦੀ ਹੈ; ਚੈਕਸਮ ਤੁਲਨਾ ਬਾਕੀ ਫੜਦੀ ਹੈ, ਅਤੇ ਅੱਪਲੋਡ ਮੁੜ ਚਲਾਉਣ ਦੇ ਮੁਕਾਬਲੇ ਦੋਵੇਂ ਸਸਤੀਆਂ ਹਨ।

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

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

ਜਦੋਂ ਹੱਦ ਫਲੈਗ ਨਹੀਂ, ਲਿੰਕ ਹੁੰਦੀ ਹੈ

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

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