rsync VPN ਰਾਹੀਂ: ਕਿਹੜਾ ਪਾਸਾ ਸੱਚ ਦਾ ਸਰੋਤ ਹੈ?

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

ਕਮਾਂਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਹੜੀ ਕਾਪੀ ਜਿੱਤਦੀ ਹੈ

ਦਿਸ਼ਾ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ, ਹਰ ਪਾਸੇ ਹੋਸਟਨਾਮ ਅਤੇ ਰਾਹ ਸਮੇਤ, ਅਤੇ ਡਾਟਾ ਦੇ ਮਾਲਕ ਤੋਂ ਮਨਜ਼ੂਰੀ ਲਓ। ਇਸ ਵਿਆਖਿਆ ਵਿੱਚ ਸਰੋਤ /srv/publish/ ਹੈ ਅਤੇ ਮੰਜ਼ਿਲ fileserver.example 'ਤੇ ਇੱਕ ਖਾਤਾ ਹੈ ਜਿਸਨੂੰ ਸਿਰਫ਼ /srv/mirror/ ਵਿੱਚ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।

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

ਕਾਪੀ ਦਾ ਪੂਰਵ-ਝਲਕ ਵੇਖੋ ਅਤੇ ਵਿਸਥਾਰ ਸੂਚੀ ਪੜ੍ਹੋ

ਕਾਪੀ ਪਹਿਲਾਂ ਪੂਰਵ-ਝਲਕ ਝੰਡੇ ਨਾਲ ਚਲਾਓ ਅਤੇ ਆਉਟਪੁੱਟ ਸੰਭਾਲ ਕੇ ਰੱਖੋ। ਵਿਸਥਾਰ ਬਦਲਾਅ ਦੱਸਦੇ ਹਨ ਕਿ ਹਰ ਰਾਹ ਨਾਲ ਕੀ ਹੋਵੇਗਾ, ਜੋ ਬਾਅਦ ਵਿੱਚ ਮਿਲਣ ਵਾਲੇ ਸਾਰ ਤੋਂ ਕਿਤੇ ਵੱਧ ਲਾਹੇਵੰਦ ਹੈ। ਆਉਟਪੁੱਟ ਨੂੰ ਬਦਲਾਅ ਰਿਕਾਰਡ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਅਗਲੀ ਵਾਰ ਚਲਾਉਣ ਵੇਲੇ ਤੁਲਨਾ ਕਰਨ ਲਈ ਕੁਝ ਹੋਵੇ।

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਮਿਟਾਉਣਾ ਸਫ਼ਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ

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

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

ਦੋ ਇੱਕ ਪਾਸੇ ਵਾਲੇ ਕੰਮ ਦੋ ਪਾਸਿਆਂ ਵਾਲਾ ਸਿੰਕ ਨਹੀਂ ਬਣਾਉਂਦੇ

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

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

ਨੀਤੀ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸਵੈਚਲਿਤ ਕਰੋ

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

ਜਦੋਂ ਸਰੋਤ ਜੀਵਤ ਡਾਟਾਬੇਸ ਜਾਂ ਹੋਰ ਬਹੁ-ਫਾਈਲ ਡਾਟਾਸੈਟ ਹੋਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਰਯਾਤ ਜਾਂ ਤਾਲਮੇਲ ਵਾਲਾ ਸਨੈਪਸ਼ਾਟ ਲਓ। ਫਾਈਲਾਂ ਦਾ ਦੁਹਰਾਉ ਭਰਮਣ ਲੈਣ-ਦੇਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਬਦਲਦੇ ਡਾਟਾਸੈਟ ਦੀ ਕਾਪੀ ਮੇਲ ਖਾਂਦੀ ਨਹੀਂ।

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