SSH ਦੇ ਜਰੀਏ rsync ਕਮਾਂਡ, ਦੋ ਸਰਵਰਾਂ ਵਿਚ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਤੇਜ਼, ਸੁਰੱਖਿਅਤ ਅਤੇ ਬਿਨਾ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਮਿਟਾਉਣ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਸਭ ਤੋਂ ਪ੍ਰਯੋਗਸ਼ੀਲ Linux ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਖਾਸ ਕਰਕੇ ਸੈਂਕੜੇ GB ਦੇ ਵੈੱਬ ਸਾਈਟ ਫਾਈਲਾਂ, ਬੈਕਅਪ ਆਰਕੀਵਾਂ, ਮੀਡੀਆ ਫੋਲਡਰਾਂ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਨੂੰ ਮਿਟਾਉਂਦੇ ਸਮੇਂ rsync ਸਿਰਫ਼ ਬਦਲ ਰਹੇ ਬਲੌਕਾਂ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਕਰਕੇ ਇਹ ਪਰੰਪਰਾਗਤ ਨਕਲ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਦੇ ਮੁਕਾਬਲੇ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਪੇਦਾ ਕਰਦਾ ਹੈ। ਬੁਨਿਆਦੀ ਵਰਤੋਂ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ: ਸਰੋਤ ਸਰਵਰ 'ਤੇ ਫਾਈਲਾਂ, SSH ਟਨਲ ਦੇ ਜਰੀਏ ਟਾਰਗੇਟ ਸਰਵਰ 'ਤੇ ਇਨਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ; ਜੇਕਰ ਸੰਪਰਕ ਟੁੱਟ ਜਾਂਦੇ ਹਨ ਤਾਂ ਕਾਰਵਾਈ ਜਿਥੇ ਛੱਡੀ ਗਈ ਸੀ ਉੱਥੇ ਜਾਰੀ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ।
ਸਰਵਰ ਮਿਟਾਉਣਾ, ਹੋਸਟਿੰਗ ਅੱਪਗਰੇਡ, ਡੇਟਾ ਸੈਂਟਰ ਬਦਲਣਾ ਜਾਂ ਬੈਕਅਪ ਓਪਰੇਸ਼ਨਾਂ ਵਿਚ ਤੇਜ਼ੀ ਦੇ ਨਾਲ-ਨਾਲ ਡੇਟਾ ਦੀ ਬਰਾਬਰੀ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ। ਵੱਡੇ ਆਰਕੀਵ ਨੂੰ ਇੱਕ ਟੁਕੜੇ ਵਿਚ ਡਾਊਨਲੋਡ ਅਤੇ ਫਿਰ ਮੁੜ ਲੋਡ ਕਰਨਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਸੰਪਰਕ ਵਿੱਚ ਗਲਤੀਆਂ ਦੇ ਕਾਰਨ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਆਵਸ਼ਕਤਾ ਪੈ ਸਕਦੀ ਹੈ। rsync ਇੱਥੇ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਫਾਈਲਾਂ ਦੇ ਸਮੇਂ ਦੇ ਛਾਪਿਆਂ, ਅਨੁਮਤੀਆਂ, ਮਾਲਕੀ ਜਾਣਕਾਰੀ ਅਤੇ ਫੋਲਡਰ ਦੇ ਢਾਂਚੇ ਨੂੰ ਬਚਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ Linux ਸਿਸਟਮ ਪ੍ਰਬੰਧਕਾਂ, DevOps ਟੀਮਾਂ ਅਤੇ ਵੈੱਬ ਹੋਸਟਿੰਗ ਵਿਸ਼ੇਸ਼ਜ್ಞਾਂ ਦੁਆਰਾ ਦਿਨਾਨੁਸਾਰ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਹੁਤ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਇਸ ਗਾਈਡ ਵਿੱਚ ਅਸੀਂ ਦੋ Linux ਸਰਵਰਾਂ ਵਿਚ SSH ਦੇ ਜਰੀਏ rsync ਨਾਲ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਮਿਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵਾਸਤਵਿਕ ਕਮਾਂਡ ਉਦਾਹਰਣਾਂ ਨਾਲ ਕਦਮ-ਦਰ-ਕਦਮ ਲੈ ਕੇ ਚੱਲਾਂਗੇ। ਇਸ ਦੇ ਨਾਲ-ਨਾਲ ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਵਧਾਉਣ ਵਾਲੇ ਪੈਰਾਮੀਟਰਾਂ, ਸੁਰੱਖਿਆ ਜਾਂਚਾਂ, ਗਲਤੀ ਦੇ ਦ੍ਰਿਸ਼ਾਂ, ਟੈਸਟ ਮਿਟਾਉਣ ਦੇ ਤਰੀਕੇ ਅਤੇ ਉਤਪਾਦਨ ਮਾਹੌਲ ਵਿਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਧਿਆਨ ਦਿੱਤੇ ਜਾਣ ਵਾਲੇ ਨੁਕਤਿਆਂ ਨੂੰ ਸਾਂਝਾ ਕਰਾਂਗੇ। ਜੇਕਰ ਤੁਸੀਂ ਨਵੀਂ VPS ਜਾਂ ਹੋਸਟਿੰਗ ਮਾਹੌਲ 'ਤੇ ਜਾਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਸ ਗਾਈਡ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਸਰੋਤ ਅਤੇ ਟਾਰਗੇਟ ਸਰਵਰਾਂ 'ਤੇ ਕਾਫੀ ਡਿਸਕ ਸਪੇਸ, SSH ਪਹੁੰਚ ਅਤੇ ਸਹੀ ਉਪਯੋਗਕਰਤਾ ਅਨੁਮਤੀਆਂ ਹਨ। ਸੰਬੰਧਿਤ ਆਧਾਰਭੂਤ ਚੋਣ ਲਈ Hostragons VPS ਸਰਵਰ ਹੱਲ ਅਤੇ Linux ਹੋਸਟਿੰਗ ਪੈਕੇਜੇ ਪੰਨਿਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ।
rsync ਕੀ ਹੈ ਅਤੇ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਮਿਟਾਉਣ ਲਈ ਕਿਉਂ ਚੁਣੀ ਜਾਂਦੀ ਹੈ?
rsync ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਕਮਾਂਡ ਲਾਈਨ ਟੂਲ ਹੈ ਜੋ ਫਾਈਲਾਂ ਅਤੇ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਸਥਾਨਕ ਸਿਸਟਮ ਜਾਂ ਦੂਰ ਦੇ ਸਰਵਰਾਂ ਵਿਚ ਸਿੰਕ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਸਦੀ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਡੈਲਟਾ ਟ੍ਰਾਂਸਫਰ ਅਲਗੋਰਿਦਮ ਹੈ। ਇਹ ਅਲਗੋਰਿਦਮ ਫਾਈਲ ਦੇ ਪੂਰੇ ਹਿੱਸੇ ਨੂੰ ਹਰ ਵਾਰੀ ਮੁੜ ਭੇਜਣ ਦੇ ਬਜਾਏ ਸਿਰਫ਼ ਬਦਲ ਰਹੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪਾਰਟੀ ਵੱਲ ਭੇਜਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇਕਰ 80 GB ਦੇ ਆਕਾਰ ਦੀ ਇੱਕ ਬੈਕਅਪ ਫਾਈਲ ਵਿੱਚ ਸਿਰਫ਼ 2 GB ਦੀ ਬਦਲਾਵ ਹੈ, ਤਾਂ ਉਚਿਤ ਹਾਲਤਾਂ ਵਿੱਚ ਪੂਰੀ ਫਾਈਲ ਨੂੰ ਮੁੜ ਮਿਟਾਉਣ ਦੇ ਬਜਾਏ ਬਦਲ ਰਹੇ ਬਲੌਕਾਂ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ।
SSH ਫਿਰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਫਾਈਲ ਸਮੱਗਰੀ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ rsync ਕਮਾਂਡ ਜਦੋਂ ਨੈੱਟਵਰਕ ਦੇ ਜਰੀਏ ਡੇਟਾ ਭੇਜਦੀ ਹੈ, ਤਾਂ ਫਾਈਲ ਸਮੱਗਰੀ ਨੂੰ ਸਧਾਰਣ ਪਾਠ ਦੇ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਲਿਆਉਂਦੀ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਗਾਹਕ ਡੇਟਾ, ਈ-ਕਾਮਰਸ ਆਰਡਰ ਰਿਕਾਰਡ, ਮੀਡੀਆ ਆਰਕੀਵ, ਡੇਟਾਬੇਸ ਬੈਕਅਪ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਐਪਲੀਕੇਸ਼ਨ ਫਾਈਲਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਹੋਸਟਿੰਗ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਸਿਰਫ਼ SSL ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਸੀਮਿਤ ਨਹੀਂ ਹੈ; ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਵਾਲਾ ਚੈਨਲ ਵੀ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵੈੱਬ ਸਾਈਟ ਟ੍ਰੈਫਿਕ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਵਰਤਦੇ ਸਮੇਂ, ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਵਿੱਚ ਵੀ SSH ਨਾਲ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਚੋਣ ਕੀਤੀ ਜानी ਚਾਹੀਦੀ ਹੈ।
rsync, FTP ਜਾਂ ਹੱਥੋਂ ਡਾਊਨਲੋਡ-ਅੱਪਲੋਡ ਮੈਥਡਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਵੱਧ ਲਚਕੀਲਾ ਹੈ। ਇਹ ਅਨੁਮਤੀਆਂ ਨੂੰ ਬਚਾ ਸਕਦਾ ਹੈ, ਪ੍ਰਤੀਕਾਤਮਕ ਲਿੰਕਾਂ ਨੂੰ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਟਾਰਗੇਟ 'ਤੇ ਮਿਟਾਈਆਂ ਗਈਆਂ ਫਾਈਲਾਂ ਨੂੰ ਵੀ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਬੈਂਡਵਿਧੀ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਕੀਤਾ ਜਾਣਾ ਹੈ, ਇਸਦਾ ਟੈਸਟ ਕਰ ਸਕਦਾ ਹੈ। ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਦਾ ਮਿਟਾਉਣਾ ਜਿਵੇਂ ਖਤਰੇ ਵਾਲੇ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਇਹ ਨਿਯੰਤਰਣ ਦੀ ਸਤਰ ਬਹੁਤ ਵੱਡਾ ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ।
ਤੁਸੀਂ ਕਦੋਂ SSH ਦੇ ਜਰੀਏ rsync ਕਮਾਂਡ ਵਰਤਣੇ ਚਾਹੀਦੇ ਹੋ?
SSH ਦੇ ਜਰੀਏ rsync ਕਮਾਂਡ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵੱਡੀਆਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਜਾਂ ਅਕਸਰ ਬਦਲ ਰਹੀਆਂ ਫਾਈਲਾਂ ਦਾ ਮਿਟਾਉਣ ਵਿੱਚ ਆਦਰਸ਼ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਵਿਜ਼ੂਅਲ ਫੋਲਡਰ ਲਈ ਹੱਥੋਂ SFTP ਕਾਫ਼ੀ ਹੋ ਸਕਦੀ ਹੈ; ਪਰ ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਫਾਈਲਾਂ, ਵੱਖ-ਵੱਖ ਅਨੁਮਤੀਆਂ ਅਤੇ ਵੱਡੇ ਆਰਕੀਵਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ rsync ਬਹੁਤ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਵਿਕਲਪ ਬਣ ਜਾਂਦੀ ਹੈ।
- ਜੇ ਤੁਸੀਂ ਪੁਰਾਣੇ ਸਰਵਰ ਤੋਂ ਨਵੀਂ VPS ਸਰਵਰ 'ਤੇ ਵੈੱਬ ਸਾਈਟ ਮਿਟਾ ਰਹੇ ਹੋ।
- ਜੇ ਤੁਸੀਂ WordPress uploads ਫੋਲਡਰ ਜਿਵੇਂ ਹਜ਼ਾਰਾਂ ਮੀਡੀਆ ਫਾਈਲਾਂ ਵਾਲੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰ ਰਹੇ ਹੋ।
- ਜੇ ਤੁਸੀਂ ਦਿਨਾਂ, ਹਫ਼ਤਿਆਂ ਜਾਂ ਮਹੀਨਿਆਂ ਦੇ ਬੈਕਅਪ ਨੂੰ ਵੱਖਰੇ ਸਰਵਰ 'ਤੇ ਕਾਪੀ ਕਰ ਰਹੇ ਹੋ।
- ਜੇ ਤੁਸੀਂ ਡੇਟਾ ਸੈਂਟਰ ਜਾਂ ਹੋਸਟਿੰਗ ਸਪਲਾਇਰ ਬਦਲ ਰਹੇ ਹੋ।
- ਜੇ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਫਾਈਲਾਂ ਨੂੰ ਉਤਪਾਦਨ ਅਤੇ ਬੈਕਅਪ ਮਾਹੌਲ ਵਿਚ ਸਿੰਕ ਕਰ ਰਹੇ ਹੋ।
- ਜੇ ਤੁਸੀਂ ਸੰਪਰਕ ਟੁੱਟਣ ਦੀ ਸੰਭਾਵਨਾ ਵਾਲੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਤੁਸੀਂ 250 GB ਖੇਤਰ ਦਾ ਮੀਡੀਆ ਫੋਲਡਰ ਆਪਣੇ ਡੈਸਕਟਾਪ ਕੰਪਿਊਟਰ 'ਤੇ ਡਾਊਨਲੋਡ ਕਰਕੇ ਫਿਰ ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਅੱਪਲੋਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਦੋ ਵੱਖਰੇ ਪ੍ਰਸਾਰਿਤ ਕਰਨੇ ਪੈਣਗੇ। ਇਹ ਨਾ ਸਿਰਫ਼ ਕੁੱਲ ਸਮੇਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਸਗੋਂ ਤੁਹਾਡੇ ਘਰ ਜਾਂ ਦਫਤਰ ਦੇ ਇੰਟਰਨੈੱਟ ਕਨੈਕਸ਼ਨ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾਉਂਦਾ ਹੈ। rsync ਦੇ ਨਾਲ ਸਰੋਤ ਸਰਵਰ ਤੋਂ ਟਾਰਗੇਟ ਸਰਵਰ 'ਤੇ ਸਿੱਧਾ ਪ੍ਰਸਾਰਿਤ ਕਰਕੇ ਤੁਸੀਂ ਇਸ ਵਿਚਕਾਰ ਦੇ ਪੜਾਅ ਨੂੰ ਹਟਾ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜੀਂਦੇ ਚੀਜ਼ਾਂ
ਸਫਲ rsync ਓਪਰੇਸ਼ਨ ਲਈ ਕਮਾਂਡ ਜਾਣਨਾ ਇਕੱਲਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਸਰੋਤ ਅਤੇ ਟਾਰਗੇਟ ਸਰਵਰ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਨਾਲ ਕਾਰਵਾਈ ਦੌਰਾਨ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਜਾਂ ਅਧੂਰੀ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਉਤਪਾਦਨ ਮਾਹੌਲਾਂ ਵਿੱਚ ਜ਼ਰੂਰੀ ਹਨ।
1. SSH ਪਹੁੰਚ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰੋ
ਸਰੋਤ ਸਰਵਰ ਤੋਂ ਟਾਰਗੇਟ ਸਰਵਰ ਤੱਕ SSH ਕਨੈਕਸ਼ਨ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਮਿਆਰੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ssh ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ਸਰਵਰ-ip। ਜੇ SSH ਵੱਖਰੇ ਪੋਰਟ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨਾਲ ਕੀਤਾ ਜਾਵੇਗਾ: ssh -p 2222 ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ਸਰਵਰ-ip। ਜੇਕਰ ਇਹ ਟੈਸਟ ਸਫਲ ਨਹੀਂ ਹੈ ਤਾਂ rsync ਵੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ। ਸੁਰੱਖਿਆ ਦੀ ਭਿਜੀ, Fail2ban, SSH ਪੋਰਟ, ਉਪਯੋਗਕਰਤਾ ਦੇ ਅਧਿਕਾਰ ਅਤੇ ਪਾਸਵਰਡ ਜਾਂ ਚਾਬੀ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
2. rsync ਪੈਕੇਜ ਦੀ ਸਥਾਪਨਾ ਦੀ ਜਾਂਚ ਕਰੋ
ਜਿਆਦਾਤਰ Linux ਡਿਸਟ੍ਰੋਜ਼ ਵਿੱਚ rsync ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ; ਫਿਰ ਵੀ ਇਸ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। Debian ਅਤੇ Ubuntu ਆਧਾਰਤ ਸਿਸਟਮਾਂ 'ਤੇ rsync --version ਕਮਾਂਡ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਇਹ ਸਥਾਪਿਤ ਨਹੀਂ ਹੈ ਤਾਂ apt install rsync ਨਾਲ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। AlmaLinux, Rocky Linux ਜਾਂ CentOS ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ dnf install rsync ਜਾਂ yum install rsync ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। Hostragons 'ਤੇ Linux ਆਧਾਰਿਤ VPS ਵਰਤਣ ਸਮੇਂ ਸਥਾਪਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ।
3. ਡਿਸਕ ਸਪੇਸ ਦੀ ਗਿਣਤੀ ਕਰੋ
ਜੇਕਰ ਟਾਰਗੇਟ ਸਰਵਰ 'ਤੇ ਕਾਫ਼ੀ ਖਾਲੀ ਸਥਾਨ ਨਹੀਂ ਹੈ ਤਾਂ ਪ੍ਰਸਾਰਿਤ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਸਰੋਤ ਡਾਇਰੈਕਟਰੀ ਦੇ ਆਕਾਰ ਨੂੰ ਵੇਖਣ ਲਈ du -sh /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ ਤਰੀਕਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਟਾਰਗੇਟ 'ਤੇ df -h ਕਮਾਂਡ ਨਾਲ ਡਿਸਕ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਫਾਈਲ ਦੇ ਆਕਾਰ ਦੇ ਬਰਾਬਰ ਸਥਾਨ ਨਹੀਂ, ਤਤਕਾਲੀ ਫਾਈਲਾਂ ਅਤੇ ਲੌਗਾਂ ਲਈ ਵੀ ਥੋੜ੍ਹਾ ਸਥਾਨ ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇਕਰ ਤੁਸੀਂ 500 GB ਡੇਟਾ ਮਿਟਾ ਰਹੇ ਹੋ ਤਾਂ ਟਾਰਗੇਟ 'ਤੇ ਘੱਟੋ-ਘੱਟ 550-600 GB ਉਪਲਬਧ ਸਥਾਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਬਹੁਤ ਸਿਹਤਮੰਦ ਹੈ।
4. ਆਵਸ਼ਕ ਸੇਵਾਵਾਂ ਅਤੇ ਬਦਲ ਰਹੀਆਂ ਫਾਈਲਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਜਿਵੇਂ ਕਿ ਜੀਵੰਤ ਚੱਲ ਰਹੀਆਂ ਵੈੱਬ ਸਾਈਟਾਂ 'ਤੇ ਫਾਈਲਾਂ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਦੌਰਾਨ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਖਾਸ ਕਰਕੇ ਉਪਯੋਗਕਰਤਾ ਦੇ ਉੱਪਰ ਲੋਡ, ਕੈਸ਼ ਫੋਲਡਰ ਅਤੇ ਲੌਗ ਫਾਈਲਾਂ ਨਿਰੰਤਰ ਨਵੀਨਤਮ ਹੁੰਦੀਆਂ ਹਨ। ਵੱਡੀਆਂ ਮਿਟਾਉਣ ਦੇ ਦੌਰਾਨ ਪਹਿਲਾਂ ਮੁਖ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਰਖਰਖਾਅ ਮੋਡ ਵਿੱਚ ਲੈ ਕੇ ਅੰਤਿਮ rsync ਚਲਾਈ ਜਾਂਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਰੁਕਾਵਟ ਦੇ ਸਮੇਂ ਨੂੰ ਮਿੰਟਾਂ ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। WordPress ਸਾਈਟਾਂ ਲਈ WordPress ਹੋਸਟਿੰਗ ਕੋਨਵਾ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਗਾਈਡ ਵਰਗੇ ਸਹਾਇਤਾ ਸਮੱਗਰੀ ਨਾਲ ਆਪਣੀ ਕਾਰਵਾਈ ਦੀ ਯੋਜਨਾ ਨੂੰ ਪੂਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਮੁੱਢਲੀ rsync ਕਮਾਂਡ: ਦੋ ਸਰਵਰਾਂ ਵਿਚ ਫਾਈਲਾਂ ਮਿਟਾਉਣਾ
ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਮੁੱਢਲੀ ਬਣਤਰ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: rsync -avz /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/। ਇੱਥੇ -a ਆਰਕਾਈਵ ਮੋਡ ਹੈ ਅਤੇ ਇਹ ਅਨੁਮਤੀਆਂ, ਸਮੇਂ ਦੇ ਛਾਪੇ, ਪ੍ਰਤੀਕਾਤਮਕ ਲਿੰਕਾਂ ਵਰਗੀਆਂ ਜਾਣਕਾਰੀਆਂ ਨੂੰ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। -v ਵਿਸਥਾਰਿਤ ਨਿਕਾਸ ਦਿੰਦਾ ਹੈ। -z ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਦੌਰਾਨ ਸੱਕੜਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਡਾਇਰੈਕਟਰੀ ਦੇ ਅੰਤ 'ਤੇ ਝੁਕਾਉ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵੇਰਵਾ ਹੈ। /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਲਿਖਣ 'ਤੇ, ਡਾਇਰੈਕਟਰੀ ਦੀ ਸਮੱਗਰੀ ਟਾਰਗੇਟ 'ਤੇ ਨਕਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ ਲਿਖਣ 'ਤੇ, ਡਾਇਰੈਕਟਰੀ ਖੁਦ ਟਾਰਗੇਟ ਦੇ ਤਹਿਤ ਬਣਾਈ ਜਾਂਦੀ ਹੈ।
ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ ਸੋਚੋ: ਤੁਸੀਂ ਪੁਰਾਣੇ ਸਰਵਰ 'ਤੇ /var/www/site/public_html/ ਫੋਲਡਰ ਵਿਚ 180 GB ਦੇ ਵੈੱਬ ਫਾਈਲਾਂ ਨੂੰ ਨਵੀਂ ਸਰਵਰ 'ਤੇ /var/www/site/public_html/ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਮਿਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਕਮਾਂਡ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/। ਇਹ ਕਾਰਵਾਈ ਸਰੋਤ ਸਰਵਰ ਤੋਂ ਟਾਰਗੇਟ ਸਰਵਰ 'ਤੇ SSH ਦੇ ਜਰੀਏ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਂਦੀ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ root ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਤਾਂ ਟਾਰਗੇਟ ਸਰਵਰ 'ਤੇ ਸੰਬੰਧਿਤ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਲਿਖਣ ਦੀ ਅਨੁਮਤੀ ਵਾਲਾ ਵਿਸ਼ੇਸ਼ ਉਪਯੋਗਕਰਤਾ ਬਣਾਉਣਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ deploy ਨਾਮਕ ਉਪਯੋਗਕਰਤਾ ਨੂੰ ਵਰਤ ਸਕਦੇ ਹੋ ਅਤੇ ਲੋੜੀਂਦੀ ਫੋਲਡਰ ਦੀ ਮਾਲਕੀ ਨੂੰ ਇਸ ਦੇ ਅਨੁਸਾਰ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ। ਉਤਪਾਦਨ ਮਾਹੌਲਾਂ ਵਿੱਚ ਸਿੱਧਾ root ਨਾਲ ਕਾਰਵਾਈ ਕਰਨਾ ਪ੍ਰਯੋਗਸ਼ੀਲ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਸੁਰੱਖਿਆ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਸੀਮਿਤ ਅਧਿਕਾਰ ਵਾਲੇ ਉਪਯੋਗਕਰਤਾ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਸਿਫਾਰਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
ਸੁਝਾਏ ਗਏ ਸੁਰੱਖਿਅਤ ਅਤੇ ਦ੍ਰੜ rsync ਪੈਰਾਮੀਟਰ
ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਦੇ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ ਸਿਰਫ਼ ਮੁੱਢਲੀ ਕਮਾਂਡ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣਾ ਹਮੇਸ਼ਾ ਸਹੀ ਨਹੀਂ ਹੁੰਦਾ। ਸੰਪਰਕ ਦੀ ਕਟੌਤੀ, ਅਧੂਰੀ ਫਾਈਲਾਂ, ਗਲਤ ਮਿਟਾਉਣ ਦੇ ਕਾਰਵਾਈਆਂ ਜਾਂ ਆਲਸੀ ਨੈੱਟਵਰਕਾਂ ਲਈ ਵਾਧੂ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਕਮਾਂਡ, ਬਹੁਤ ਸਾਰੇ ਵਾਸਤਵਿਕ ਮਿਟਾਉਣ ਦੇ ਸਿਨਾਰਿਓਜ਼ ਲਈ ਇਕ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤ ਬਿੰਦੂ ਹੈ:
rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/
ਇਸ ਕਮਾਂਡ ਦਾ -a ਆਰਕਾਈਵ ਮੋਡ, -H ਹਾਰਡ ਲਿੰਕ ਜਾਣਕਾਰੀ, -A ACL ਅਨੁਮਤੀਆਂ, -X ਵਿਸ਼ਤ੍ਰਿਤ ਗੁਣਾਂ ਦੇ ਮੁੱਲ ਨੂੰ ਬਚਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। --numeric-ids ਉਪਯੋਗਕਰਤਾ ਅਤੇ ਸਮੂਹ ਨਾਮਾਂ ਦੀ ਬਜਾਏ ID ਮੁੱਲਾਂ ਨੂੰ ਆਧਾਰਿਤ ਕਰਦਾ ਹੈ; ਜਦੋਂ ਵੱਖਰੇ ਸਰਵਰਾਂ 'ਤੇ ਉਪਯੋਗਕਰਤਾ ਨਾਮ ਬਦਲਦੇ ਹਨ ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ। --partial ਅਧੂਰੀ ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਣ ਦੇ ਬਿਨਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ। --progress ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੀ ਸਥਿਤੀ ਦਿਖਾਉਂਦਾ ਹੈ। --append-verify ਖਾਸ ਤੌਰ 'ਤੇ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਜਦੋਂ ਜਿਥੇ ਛੱਡਿਆ ਗਿਆ ਸੀ ਉੱਥੇ ਜਾਰੀ ਰੱਖਣ ਦੇ ਦੌਰਾਨ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਿੱਸੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਹਰ ਪੈਰਾਮੀਟਰ ਹਰ ਸਿਸਟਮ 'ਤੇ ਲੋੜੀਦਾ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਸਧਾਰਣ ਵੈੱਬ ਸਾਈਟ ਨੂੰ ਮਿਟਾਉਣ ਵਿੱਚ -aHAX ਦੀ ਵਰਤੋਂ ਕਾਫ਼ੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਵਿਸ਼ੇਸ਼ ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਦੇ ਨਾਲ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ACL ਅਤੇ ਵਿਸ਼ਤ੍ਰਿਤ ਗੁਣਾਂ ਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਬਚਾਉਣਾ ਨਾਜ਼ੁਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਪਹਿਲਾਂ ਟੈਸਟ ਮਿਟਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਵੱਖਰੇ SSH ਪੋਰਟ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਕਮਾਂਡ ਕਿਵੇਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?

ਸੁਰੱਖਿਆ ਲਈ SSH ਪੋਰਟ 22 ਦੇ ਬਜਾਏ ਵੱਖਰੇ ਪੋਰਟ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਹਾਲਤ ਵਿੱਚ rsync ਵਿਚ SSH ਪੈਰਾਮੀਟਰ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ: rsync -avz -e ssh -p 2222 /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/। ਪਰ ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ -e ਪੈਰਾਮੀਟਰ ਦਾ ਮੁੱਲ ਇਕੱਠੇ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਹੀ ਵਰਤੋਂ ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ: rsync -avz -e 'ssh -p 2222' /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/।
JSON ਅਤੇ ਕੁਝ ਪੈਨਲਾਂ ਵਿੱਚ ਇਕਲੀਆਂ ਉਪਯੋਗ ਕਰਨਾ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਟਰਮੀਨਲ 'ਤੇ ਸਿੱਧਾ ਲਿਖਦੇ ਸਮੇਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਧਾਰਾਂ ਸਹੀ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ SSH ਕੁੰਜੀ ਦੇ ਨਾਲ ਜੁੜ ਰਹੇ ਹੋ ਤਾਂ -i ਪੈਰਾਮੀਟਰ ਵੀ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/। ਇਹ ਤਰੀਕਾ ਆਟੋਮੇਸ਼ਨ ਅਤੇ cron ਅਧਾਰਿਤ ਬੈਕਅਪ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਅਕਸਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ: --dry-run ਦੀ ਵਰਤੋਂ
ਵੱਡੇ ਡੇਟਾ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਸਭ ਤੋਂ ਵਿਸ਼ੇਸ਼ ਕਾਰਵਾਈਆਂ ਵਿੱਚੋਂ ਇੱਕ --dry-run ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ। ਇਹ ਪੈਰਾਮੀਟਰ ਫਾਈਲਾਂ ਨੂੰ ਵਾਸਤਵਿਕ ਤੌਰ 'ਤੇ ਨਕਲ ਨਹੀਂ ਕਰਦਾ; ਸਿਰਫ਼ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਮਿਟਾਉਣ ਲਈ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ ਗਲਤ ਡਾਇਰੈਕਟਰੀ, ਗਲਤ ਟਾਰਗੇਟ ਪਾਸੇ ਜਾਂ ਅਣਜਾਣ ਮਿਟਾਉਣ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਨ ਟੈਸਟ ਕਮਾਂਡ: rsync -avz --dry-run /var/www/site/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/var/www/site/। ਨਿਕਾਸ ਵਿੱਚ ਤੁਸੀਂ ਮਿਟਾਉਣ ਵਾਲੀਆਂ ਫਾਈਲਾਂ, ਬਣਾਈਆਂ ਜਾਣ ਵਾਲੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ ਕਾਰਵਾਈ ਦਾ ਸੰਖੇਪ ਵੇਖ ਸਕਦੇ ਹੋ। ਜੇਕਰ --delete ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ ਤਾਂ dry-run ਹੋਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੀ ਹੈ। ਕਿਉਂਕਿ --delete, ਸਰੋਤ ਵਿੱਚ ਨਹੀਂ ਹੋਣ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਟਾਰਗੇਟ 'ਤੇ ਮਿਟਾ ਸਕਦੀ ਹੈ। ਸਹੀ ਵਰਤੋਂ 'ਤੇ ਇਹ ਟਾਰਗੇਟ ਨੂੰ ਬਿਲਕੁਲ ਇੱਕ ਸਾਏ ਦੇ ਰੂਪ ਵਿੱਚ ਬਣਾ ਦਿੰਦਾ ਹੈ; ਗਲਤ ਡਾਇਰੈਕਟਰੀ 'ਤੇ ਵਰਤਣ 'ਤੇ ਇਹ ਗੰਭੀਰ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਪੇਸ਼ੇਵਰ ਕਾਰਵਾਈ ਦੀ ਕ੍ਰਮਵਾਰਤਾ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦੀ ਹੈ: ਪਹਿਲਾਂ SSH ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਡਿਸਕ ਸਪੇਸ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਫਿਰ rsync --dry-run ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਛੋਟੀ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਵਾਸਤਵਿਕ ਟੈਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਮੁਖ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੀ ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਵਾਧੂ ਸਮੇਂ ਦੀ ਲੋੜ ਕਰਦੀ ਹੈ ਪਰ ਘੰਟੇ ਲੰਬੇ ਗਲਤ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਸੱਕੜਨ, ਬੈਂਡਵਿਧੀ ਅਤੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਸੈਟਿੰਗਾਂ
rsync ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਸਿਰਫ਼ ਫਾਈਲ ਦੇ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੈ। ਸਰਵਰਾਂ ਦੀ CPU ਸ਼ਕਤੀ, ਡਿਸਕ ਕਿਸਮ, ਨੈੱਟਵਰਕ ਦੇ ਲੇਟਨਸੀ, ਬੈਂਡਵਿਧੀ ਅਤੇ ਫਾਈਲਾਂ ਦੀ ਗਿਣਤੀ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀ ਫਾਈਲਾਂ, ਇੱਕ ਵੱਡੀ ਫਾਈਲ ਨਾਲੋਂ ਹੌਲੀ ਨਾਲ ਮਿਟਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ; ਕਿਉਂਕਿ ਹਰ ਫਾਈਲ ਲਈ ਮੈਟਾਡੇਟਾ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। NVMe ਡਿਸਕ ਵਾਲੇ VPS ਮਾਹੌਲਾਂ ਵਿੱਚ ਫਾਈਲਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨ ਅਤੇ ਲਿਖਣ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਬਿਹਤਰ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ ਜੇਕਰ ਤੁਸੀਂ ਭਾਰੀ ਮਿਟਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ ਤਾਂ NVMe VPS ਸਰਵਰ ਚੋਣਾਂ ਨੂੰ ਦੇਖਣਾ ਸਮਝਦਾਰੀ ਹੈ।
-z ਸੱਕੜਨ ਪੈਰਾਮੀਟਰ ਮੈਟੈਕਸਟ ਫਾਈਲਾਂ, ਲੌਗਾਂ ਅਤੇ ਕੁਝ ਬੈਕਅਪ ਕਿਸਮਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ। ਪਰ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਸੱਕੜੀ ਹੋਈ zip, tar.gz, jpg, mp4 ਜਾਂ gzip ਫਾਈਲਾਂ 'ਤੇ CPU ਦੀ ਖਪਤ ਕਰਕੇ ਬਹੁਤ ਵਧੀਆ ਫਾਇਦੇ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਜੇਕਰ ਤੁਸੀਂ 1 Gbps ਕਨੈਕਸ਼ਨ ਵਾਲੇ ਦੋ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਰਵਰਾਂ ਵਿਚ ਵੱਡੀਆਂ ਮੀਡੀਆ ਫਾਈਲਾਂ ਮਿਟਾ ਰਹੇ ਹੋ, ਤਾਂ -z ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਮਿਲ ਸਕਦਾ ਹੈ। ਇਸ ਦੇ ਵਿਰੁੱਧ, ਨੀਵੀਂ ਬੈਂਡਵਿਧੀ 'ਤੇ ਅਤੇ ਮੈਟੈਕਸਟ ਭਾਰੀ ਫਾਈਲਾਂ ਵਿੱਚ -z ਮਹੱਤਵਪੂਰਨ ਬਚਤ ਕਰ ਸਕਦਾ ਹੈ।
ਬੈਂਡਵਿਧੀ ਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ --bwlimit ਦਾ ਉਪਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ --bwlimit=50000 ਲਗਭਗ 50 MB/s ਦੀ ਪੱਧਰੀ ਸੀਮਾ ਰੱਖਦਾ ਹੈ। ਇਹ ਜੀਵੰਤ ਵੈੱਬ ਸਾਈਟ ਦੇ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੁਕਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਤਪਾਦਨ ਸਰਵਰ 'ਤੇ ਭਾਰੀ ਘੜੀਆਂ ਦੇ ਦੌਰਾਨ ਪੂਰੀ ਗਤੀ ਨਾਲ ਮਿਟਾਉਣ ਨਾਲ ਦਰਸ਼ਕ ਦੇ ਤਜਰਬੇ ਨੂੰ ਨਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪੈ ਸਕਦਾ ਹੈ। ਮਿਟਾਉਣ ਨੂੰ ਰਾਤ ਦੇ ਸਮਿਆਂ ਵਿਚ ਯੋਜਨਾ ਬਣਾਉਣਾ, ਬੈਂਡਵਿਧੀ ਦੀ ਸੀਮਾ ਰੱਖਣਾ ਅਤੇ ਕਾਰਵਾਈ ਦੌਰਾਨ ਲੋਡ ਮੰਢਲ ਦੇ ਮੁੱਲਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਚੰਗੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।
rsync, scp, SFTP ਅਤੇ FTP ਦੀ ਤੁਲਨਾ
ਫਾਈਲਾਂ ਨੂੰ ਮਿਟਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰੇ ਤਰੀਕੇ ਹਨ; ਪਰ ਹਰ ਤਰੀਕੇ ਦੇ ਮਜ਼ਬੂਤ ਅਤੇ ਕਮਜ਼ੋਰ ਪੱਖ ਵੱਖਰੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤਾ ਟੇਬਲ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਅਤੇ ਸਰਵਰ ਮਿਟਾਉਣ ਦੇ ਸਿਨਾਰਿਓਜ਼ ਵਿੱਚ ਕਿਹੜਾ ਉਪਕਰਣ ਕਦੋਂ ਵਧੀਆ ਹੈ, ਇਸਦਾ ਸਰਵੇਖਣ ਕਰਦਾ ਹੈ।
| ਤਰੀਕਾ | ਸੁਰੱਖਿਆ | ਕਿਥੇ ਰੁਕਣ | ਵੱਡੀ ਫਾਈਲ ਪ੍ਰਦਰਸ਼ਨ | ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਤੋਂ |
|---|---|---|---|---|
| rsync + SSH | ਉੱਚ | ਮਜ਼ਬੂਤ | ਬਹੁਤ ਚੰਗਾ | ਸਰਵਰ ਮਿਟਾਉਣਾ, ਬੈਕਅਪ, ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ |
| scp | ਉੱਚ | ਸੀਮਿਤ | ਮੱਧ | ਘੱਟ ਫਾਈਲਾਂ ਦਾ ਤੇਜ਼ੀ ਨਾਲ ਨਕਲ ਕੀਤਾ ਜਾਣਾ |
| SFTP | ਉੱਚ | ਗਾਹਕ 'ਤੇ ਨਿਰਭਰ | ਮੱਧ | ਹੱਥੋਂ ਫਾਈਲ ਪ੍ਰਬੰਧਨ |
| FTP | ਨਿਮਨ | ਗਾਹਕ 'ਤੇ ਨਿਰਭਰ | ਵੱਖਰੇ | ਸੁਰੱਖਿਆ ਆਵਸ਼ਕ ਨਹੀਂ ਹੈ ਤਾਂ ਪੁਰਾਣੇ ਸਿਸਟਮਾਂ |
ਟੇਬਲ ਤੋਂ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ ਕਿ rsync, ਵਿਸ਼ੇਸ਼ ਕਰਕੇ ਦੁਹਰਾਈ ਜਾ ਰਹੀ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨਾਂ ਅਤੇ ਵੱਡੇ ਡੇਟਾ ਦੀ ਮਿਟਾਉਣ ਵਿੱਚ ਅੱਗੇ ਹੈ। scp ਸਧਾਰਣ ਅਤੇ ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਹੈ ਪਰ ਬਦਲ ਰਹੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਮਝਣ ਦੇ ਮਾਮਲੇ ਵਿੱਚ rsync ਦੀ ਤਰ੍ਹਾਂ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨਹੀਂ ਹੈ। FTP ਨੂੰ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਬਿਨਾਂ ਵਰਤਣ 'ਤੇ ਆਧੁਨਿਕ ਸੁਰੱਖਿਆ ਮਿਆਰਾਂ ਲਈ ਉਚਿਤ ਨਹੀਂ ਹੈ। ਹੋਸਟਿੰਗ ਪੈਨਲਾਂ ਵਿੱਚ FTP ਪਹੁੰਚ ਪ੍ਰਯੋਗਸ਼ੀਲ ਹੋ ਸਕਦੀ ਹੈ; ਪਰ ਸਰਵਰਾਂ ਦੇ ਵਿਚਕਾਰ ਨਾਜ਼ੁਕ ਮਿਟਾਉਣ ਦੇ ਦੌਰਾਨ SSH ਦੇ ਆਧਾਰਿਤ ਤਰੀਕੇ ਦੀ ਚੋਣ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਜੀਵੰਤ ਵੈੱਬ ਸਾਈਟ ਮਿਟਾਉਣ ਲਈ ਉਦਾਹਰਨ ਕਾਰਵਾਈ
ਇੱਕ ਵੈੱਬ ਸਾਈਟ ਨੂੰ ਪੁਰਾਣੇ ਸਰਵਰ ਤੋਂ ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਮਿਟਾਉਣ ਦਾ ਉਦੇਸ਼ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਨਹੀਂ ਹੈ। DNS, ਡੇਟਾਬੇਸ, SSL, PHP ਸੰਸਕਰਣ, ਫਾਈਲਾਂ ਦੀਆਂ ਅਨੁਮਤੀਆਂ ਅਤੇ ਈ-ਮੇਲ ਸੈਟਿੰਗਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਵੱਡੇ ਫਾਈਲਾਂ ਵਾਲੇ ਵੈੱਬ ਸਾਈਟ ਲਈ ਘੱਟ ਰੁਕਾਵਟ ਵਾਲੀ ਉਦਾਹਰਨ ਕਾਰਵਾਈ ਦਿੱਤੀ ਗਈ ਹੈ।
- ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਵੈੱਬ ਸਰਵਰ, PHP, ਡੇਟਾਬੇਸ ਅਤੇ ਲੋੜੀਂਦੇ ਮੋਡਿਊਲ ਬਣਾਓ।
- ਡੋਮੇਨ ਦੇ DNS TTL ਮੁੱਲ ਨੂੰ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ 300 ਸਕਿੰਟਾਂ ਵਰਗੇ ਘੱਟ ਮੁੱਲ 'ਤੇ ਲਿਆਓ। ਡੋਮੇਨ ਪ੍ਰਬੰਧਨ ਲਈ ਡੋਮੇਨ ਪੁੱਛਤਾਛ ਅਤੇ ਡੋਮੇਨ ਪ੍ਰਬੰਧਨ ਪੰਨਾ ਦੇਖਣਾ ਚੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
- ਪਹਿਲੀ rsync ਮਿਟਾਉਣ ਨੂੰ ਸਾਈਟ ਦੀ ਜੀਵਨਤ ਸਮੇਂ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਸਟੇਜ 'ਤੇ ਵੱਡੀ ਡੇਟਾ ਦੀ ਜ਼ਿਆਦਾਤਰ ਮਿਟਾਉਣ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
- ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅਪ ਲਓ ਅਤੇ ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰੋ।
- ਸਾਈਟ ਨੂੰ ਛੋਟੀ ਸਮੇਂ ਲਈ ਰੱਖਰਖਾਅ ਮੋਡ ਵਿੱਚ ਲੈ ਆਓ।
- ਦੂਜੀ rsync ਕਮਾਂਡ ਚਲਾਕੇ ਬਦਲ ਰਹੀਆਂ ਆਖਰੀ ਫਾਈਲਾਂ ਨੂੰ ਸਿੰਕ ਕਰੋ।
- ਡੇਟਾਬੇਸ ਨੂੰ ਦੁਬਾਰਾ ਅਪਡੇਟ ਕਰੋ ਜਾਂ ਇਨਕ੍ਰੀਮੈਂਟਲ ਰਣਨੀਤੀ ਵਰਤੋਂ ਕਰੋ।
- ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਫਾਈਲਾਂ ਦੀਆਂ ਅਨੁਮਤੀਆਂ, ਸਾਈਟ ਦੀ ਖੋਲ੍ਹਾਈ ਅਤੇ ਲੌਗਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
- SSL ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ ਜਾਂ ਨਵੀਨੀਕਰਨ ਕਰੋ। ਇਸ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਸਥਾਪਨਾ ਸਮੱਗਰੀ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ।
- DNS ਰਿਕਾਰਡਾਂ ਨੂੰ ਨਵੀਂ IP ਪਤੇ 'ਤੇ ਮੋੜੋ।
ਇਸ ਤਰੀਕੇ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਣ ਵਾਲੀ ਮੁੱਖ ਫਾਈਲ ਮਿਟਾਉਣ ਦੀ ਕਾਰਵਾਈ ਸਾਈਟ ਚਾਲੂ ਹੋਣ ਦੌਰਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਰੁਕਾਵਟ ਸਿਰਫ਼ ਆਖਰੀ ਸਿੰਕ ਅਤੇ DNS ਮੋੜ ਦੇ ਦੌਰਾਨ ਹੁੰਦੀ ਹੈ। ਵੱਡੀਆਂ ਮੀਡੀਆ ਆਰਕੀਵ ਵਾਲੀਆਂ WordPress ਸਾਈਟਾਂ ਵਿੱਚ ਇਹ ਪਹੁੰਚ ਘੰਟਿਆਂ ਦੀ ਲੰਬੀ ਰੁਕਾਵਟ ਨੂੰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਘਟਾ ਸਕਦੀ ਹੈ।
ਡੇਟਾ ਦੀ ਸੁਰੱਖਿਆ ਦੀ ਜਾਂਚ
ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੇ ਪੂਰਨ ਹੋਣ 'ਤੇ ਸਿਰਫ਼ ਕਮਾਂਡ ਦਾ ਖਤਮ ਹੋਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਫਾਈਲਾਂ ਦੀ ਗਿਣਤੀ, ਆਕਾਰ ਅਤੇ ਆਵਸ਼ਕ ਫਾਈਲਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਧਾਰਣ ਜਾਂਚ ਲਈ ਸਰੋਤ ਅਤੇ ਟਾਰਗੇਟ 'ਤੇ du -sh ਕਮਾਂਡ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਦੇ ਆਕਾਰ ਬਰਾਬਰ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਪਰ ਫਾਈਲ ਸਿਸਟਮ ਦੇ ਬਲੌਕ ਫਰਕਾਂ ਕਾਰਨ ਮੁੱਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਇੱਕ ਜੇਹੇ ਨਹੀਂ ਦਿਖਾਈ ਦੇ ਸਕਦੇ। ਜ਼ਿਆਦਾ ਵੇਰਵਾ ਜਾਂਚ ਲਈ rsync ਨੂੰ ਦੁਬਾਰਾ ਉਨ੍ਹਾਂ ਹੀ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਲਈ ਕੋਈ ਨਵੀਂ ਫਾਈਲ ਨਹੀਂ ਹੈ, ਤਾਂ ਨਿਕਾਸ ਘੱਟੋ-ਘੱਟ ਹੁੰਦਾ ਹੈ।
Checksum ਦੀ ਪੁਸ਼ਟੀ ਲਈ rsync -avc --dry-run /ਸਰੋਤ/ਡਾਇਰੈਕਟਰੀ/ ਉਪਯੋਗਕਰਤਾ@ਟਾਰਗੇਟ-ip:/ਟਾਰਗੇਟ/ਡਾਇਰੈਕਟਰੀ/ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇੱਥੇ -c ਪੈਰਾਮੀਟਰ ਫਾਈਲਾਂ ਨੂੰ ਸਮੇਂ ਦੇ ਛਾਪੇ ਅਤੇ ਆਕਾਰ ਦੇ ਨਾਲ ਨਾਲ checksum ਨਾਲ ਵੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਵੱਡੇ ਡੇਟਾ ਵਿੱਚ CPU ਅਤੇ ਡਿਸਕ ਦੀ ਭਾਰਕ ਬਣਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਧਿਆਨ ਨਾਲ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਵਸ਼ਕ ਆਰਕੀਵਾਂ, ਡੇਟਾਬੇਸ ਡੰਪ ਫਾਈਲਾਂ ਜਾਂ ਗਾਹਕ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਇਹ ਵਾਧੂ ਪੁਸ਼ਟੀ ਸੁਰੱਖਿਆ ਦਿੰਦੀ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਵੈੱਬ ਸਾਈਟ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਹੈ ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ ਵੀ ਜਾਂਚ ਕਰੋ। ਮੁੱਖ ਪੰਨਾ, ਪ੍ਰਬੰਧਨ ਪੈਨਲ, ਵਿਜ਼ੂਅਲ ਅੱਪਲੋਡ, ਭੁਗਤਾਨ ਪੰਨਾ, ਸੰਪਰਕ ਫਾਰਮ ਅਤੇ ਗਲਤੀ ਦੇ ਲੌਗਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਈ-ਕਾਮਰਸ ਸਾਈਟਾਂ 'ਤੇ ਸਿਰਫ਼ ਫਾਈਲਾਂ ਦਾ ਮਿਟਾਉਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ; ਭੁਗਤਾਨ ਇੰਟਿਗਰੇਸ਼ਨ ਅਤੇ cron ਕਾਰਜਾਂ ਨੂੰ ਵੀ ਨਵੀਂ ਸਰਵਰ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।