SSH મારફતે rsync કમાન્ડ બે સર્વરો વચ્ચે મોટા ફાઇલો ઝડપથી, સુરક્ષિત રીતે અને મિડ-ટ્રાન્સફર અટકાવાની સ્થિતિમાં ફરીથી ચાલુ કરી શકાય તેવા રીતે ટ્રાન્સફર કરવા માટેનું સૌથી અસરકારક લિનક્સ ટૂલ છે. ખાસ કરીને સેકડો GBના વેબસાઇટ ફાઇલો, બેકઅપ આર્કાઇવ, મીડિયા ફોલ્ડર્સ અથવા એપ્લિકેશન ડેટા ટ્રાન્સફર કરતી વખતે rsync માત્ર બદલાયેલા બ્લોક્સ જ મોકલે છે, જે પરંપરાગત કૉપિ કરતાં બહુ ઝડપી અને અસરકારક છે. તેનો મૂળ સિદ્ધાંત એ છે કે: સોર્સ સર્વર上的 ફાઇલો SSH ટનલ મારફતે એન્ક્રિપ્ટેડ રીતે ટાર્ગેટ સર્વર પર સમકક્ષ બનાવવામાં આવે છે; જો કનેક્શન કાપાય તો ટ્રાન્સફર ત્યાંથી ચાલુ રાખી શકાય છે.
સર્વર માઈગ્રેશન, હોસ્ટિંગ અપગ્રેડ, ડેટા સેન્ટર બદલાવ અથવા બેકઅપ ઓપરેશન્સમાં ગતિ એટલી જ મહત્વની છે જેટલી ડેટાની પૂર્ણતા. મોટા આર્કાઇવને એકબાર ડાઉનલોડ કરીને ફરીથી અપલોડ કરવું સમય બગાડે છે અને કનેક્શન તૂટવા પર ફરીથી શરૂ કરવું પડે છે. rsync આ સમસ્યાનું સમાધાન કરીને ફાઇલના ટાઈમસ્ટેમ્પ, પરવાનગીઓ, માલિકી અને ફોલ્ડર સ્ટ્રક્ચરને જાળવી શકે છે. આ કારણે લિનક્સ સિસ્ટમ એડમિન, DevOps ટીમો અને વેબ હોસ્ટિંગ નિષ્ણાતો દરરોજના કામમાં rsync ને પસંદ કરે છે.
આ માર્ગદર્શિકા બે લિનક્સ સર્વરો વચ્ચે SSH દ્વારા rsync વડે મોટા ફાઇલો કેવી રીતે ટ્રાન્સફર કરવાના છે તે વાસ્તવિક કમાન્ડ ઉદાહરણો સાથે વિગતે સમજાવશે. સાથે જ કાર્યક્ષમતા વધારવાના વિકલ્પો, સુરક્ષા તપાસો, ભૂલ સંભાળવા માટેની પદ્ધતિઓ, ટેસ્ટ ટ્રાન્સફર અને પ્રોડક્શનમાં જવા પહેલાં ધ્યાનમાં લેવા જેવી બાબતો શૅર કરશે. જો તમે નવી VPS કે હોસ્ટિંગ પર ઇમિગ્રેટ કરવાના વિચારી રહ્યા છો, તો ખાતરી કરો કે સોર્સ અને ટાર્ગેટ સર્વરમાં પૂરતા ડિસ્ક સ્પેસ, SSH એક્સેસ અને યોગ્ય યુઝર પરમિશન્સ છે. સંબંધિત ઈન્ફ્રાસ્ટ્રક્ચર માટે Hostragons VPS સર્વર ઉકેલ અને લિનક્સ હોસ્ટિંગ પેકેજો પૃષ્ઠો જોઈ શકો છો.
rsync શું છે અને મોટા ફાઇલો ટ્રાન્સફરમાં શા માટે ઉપયોગી છે?
rsync એ એક શક્તિશાળી કમાન્ડ-લાઇન ટૂલ છે જે સ્થાનિક અથવા રિમોટ સર્વરો વચ્ચે ફાઇલ અને ડિરેક્ટરીઝને સમકક્ષ બનાવવામાં મદદ કરે છે. તેની સૌથી મોટી વિશેષતા ડેલ્ટા ટ્રાન્સફર એલ્ગોરિધમ છે, જે ફાઇલનો સંપૂર્ણ ડેટા ફરીથી મોકલવાને બદલે ફક્ત બદલાયેલા ભાગો જ મોકલે છે. ઉદાહરણ તરીકે, 80 GB વજનવાળા બેકઅપ ફાઇલમાં જો માત્ર 2 GB જ બદલાયું હોય, તો સંપૂર્ણ ફાઇલ ફરીથી મોકલવાને બદલે ફક્ત બદલાયેલા બ્લોક્સ જ ટ્રાન્સફર થાય છે.
SSH ટ્રાન્સફરને એન્ક્રિપ્ટ કરે છે. આથી rsync નેટવર્ક પર ડેટા મોકલતી વખતે ફાઇલનું કન્ટેન્ટ પ્લેઇન ટેક્સ્ટમાં નથી મોકલતું. આ ખાસ કરીને ગ્રાહક ડેટા, ઇ-કોમર્સ ઓર્ડર રેકોર્ડ્સ, મીડિયા આર્કાઇવ, ડેટાબેઝ બેકઅપ અને ખાનગી એપ્લિકેશન ફાઇલો માટે મહત્વનું છે. હોસ્ટિંગ જગતમાં ડેટા સુરક્ષા માત્ર SSL સર્ટિફિકેટ સુધી મર્યાદિત નથી; સર્વરો વચ્ચેનો ટ્રાન્સફર ચેનલ પણ સુરક્ષિત હોવો જરૂરી છે. વેબસાઈટ ટ્રાફિક માટે SSL પ્રમાણપત્ર વાપરતાં, સર્વરો વચ્ચે ફાઇલ ટ્રાન્સફરમાં SSH એન્ક્રિપ્શન જરૂરી છે.
rsync FTP કે મેન્યુઅલ ડાઉનલોડ-અપલોડ કરતાં વધુ લવચીક છે. તે પરવાનગીઓ જાળવી શકે છે, સિમ્બોલિક લિંક્સ ટ્રાન્સફર કરી શકે છે, ટાર્ગેટમાં ડિલીટ કરેલ ફાઇલો પણ હટાવી શકે છે, બૅન્ડવિડ્થ મર્યાદિત કરી શકે છે અને ટ્રાન્સફર પહેલાં ટેસ્ટ ચલાવી શકે છે. મોટા ફાઇલ ટ્રાન્સફરમાં આ નિયંત્રણ સ્તર બહુ ફાયદાકારક સાબિત થાય છે.
ક્યારે SSH મારફતે rsync કમાન્ડ વાપરવી જોઈએ?
SSH દ્વારા rsync ખાસ કરીને મોટા, ઘણાબધા કે વારંવાર બદલાતા ફાઇલ ટ્રાન્સફર માટે પરફેક્ટ છે. સામાન્ય રીતે થોડા ફોટા માટે મેન્યુઅલ SFTP પૂરતું હોય છે, પરંતુ હજારો ફાઇલો, અલગ-અલગ પરવાનગીઓ અને મોટા આર્કાઇવ માટે rsync વધુ વિશ્વસનીય વિકલ્પ છે.
- જૂના સર્વર પરથી નવી VPS સર્વર પર વેબસાઈટ ટ્રાન્સફર કરતા હોવ.
- વર્ડપ્રેસ uploads જેવા હજારો મીડિયા ફાઇલો ધરાવતા ફોલ્ડર્સ ટ્રાન્સફર કરતા હોવ.
- દૈનિક, સાપ્તાહિક કે માસિક બેકઅપ અલગ સર્વર પર કોપી કરતા હોવ.
- ડેટા સેન્ટર અથવા હોસ્ટિંગ પ્રદાતા બદલતા હોવ.
- એપ્લિકેશન ફાઇલો પ્રોડક્શન અને બેકઅપ વચ્ચે સમકક્ષ રાખતા હોવ.
- લાંબા સમયના ટ્રાન્સફર માટે કનેક્શન ટૂટી શકે તે સંભાવના હોય.
ઉદાહરણ તરીકે, 250 GB માધ્યમિક ફોલ્ડરને પહેલા તમારા ડેસ્કટોપ પર ડાઉનલોડ કરીને પછી નવી સર્વર પર અપલોડ કરવું બે અલગ ટ્રાન્સફર રહેશે. આથી સમય વધે છે અને ઈન્ટરનેટ સ્પીડ પણ સ્લો થઇ શકે છે. rsync વડે સીધા સોર્સથી ટાર્ગેટ સર્વરને ટ્રાન્સફર કરી આ વચ્ચેનું પગલું દૂર કરી શકાય છે.
શરૂઆત પહેલા જરૂરી તૈયારી
સફળ rsync ઓપરેશન માટે માત્ર કમાન્ડ જાણવું પૂરતું નથી. સોર્સ અને ટાર્ગેટ સર્વરની સ્થિતિ ચકાસવી પણ જરૂરી છે જેથી ડેટા લૉસ અથવા અર્ધાંગ ટ્રાન્સફરનો જોખમ ઘટાડાય. નીચેના ચેકલિસ્ટ પ્રોડક્શન એન્વાયર્નમેન્ટમાં ખાસ ધ્યાનમાં લેવો જોઈએ.
1. SSH કનેક્શન ચકાસો
સોર્સ સર્વર પરથી ટાર્ગેટ સર્વર સુધી SSH કનેક્શન જવું જોઈએ. સામાન્ય રીતે ssh યુઝર@ટાર્ગેટ-IP દ્વારા ચકાસાય છે. જો SSH પોર્ટ ડિફોલ્ટ 22 સિવાય હોય તો ssh -p પોર્ટ યુઝર@ટાર્ગેટ-IP આ રીતે ટ્રાય કરો. જો આ સ્ટેપ ફેલ થાય તો rsync કામ નહીં કરે. ફાયરવોલ, Fail2ban, SSH પોર્ટ, યુઝર પરમિશન અને પાસવર્ડ કે કી ઓથેન્ટિકેશન તપાસો.
2. rsync પેકેજ ઇન્સ્ટોલ છે કે નહીં તે તપાસો
લિનક્સ ડિસ્ટ્રિબ્યુશનમાં rsync સામાન્ય રીતે ઈન્સ્ટોલ આવે છે, પરંતુ ચકાસવું જરૂરી છે. Debian/Ubuntuમાં rsync --version ચલાવો. જો નથી તો apt install rsync કરવું. AlmaLinux, Rocky Linux કે CentOSમાં dnf install rsync અથવા yum install rsync વાપરો. Hostragons VPS પર લિનક્સ હોય તો સામાન્ય રીતે rsync quelques સેકન્ડમાં ઈન્સ્ટોલ થઇ જાય છે.
3. ડિસ્ક સ્પેસ ચકાસો
ટાર્ગેટ સર્વરમાં પૂરતો ખાલી ડિસ્ક સ્પેસ ન હોય તો ટ્રાન્સફર અધૂરો રહેશે. સોર્સ ડિરેક્ટરીનું કદ du -sh /path/to/source થી જાણી શકાય છે. ટાર્ગેટ પર df -h વડે ડિસ્ક સ્ટેટસ જોઈએ. ફક્ત ફાઇલ સાઇઝ જેટલો નહીં, ટેમ્પ અને લોગ ફાઇલો માટે પણ થોડી જગ્યા છોડવી જોઈએ. ઉદાહરણ તરીકે, 500 GB ડેટા ટ્રાન્સફર માટે ટાર્ગેટમાં ઓછામાં ઓછું 550-600 GB ફ્રી હોવી સારું.
4. મહત્વના સર્વિસ અને બદલાતા ફાઇલો માટે પ્લાન બનાવો
લાઇવ વેબસાઇટ પર ફાઇલો ટ્રાન્સફર દરમ્યાન બદલાતા રહે છે, ખાસ કરીને યૂઝર અપલોડ, કેશ ફોલ્ડર અને લોગ ફાઇલ્સ. મોટા ટ્રાન્સફરમાં પહેલા મુખ્ય ડેટા મોકલીને, પછી સાઇટમાં મેન્ટનન્સ મોડ લગાવીને છેલ્લી rsync ચલાવવી જોઈએ. આથી ડાઉનટાઈમ ઓછો થાય છે. વર્ડપ્રેસ માટે વોર્ડપ્રેસ હોસ્ટિંગ પરિવહન માર્ગદર્શિકા જેવી ઉપયોગી સામગ્રી જોઈ શકો છો.
મૂળભૂત rsync કમાન્ડ: બે સર્વરો વચ્ચે ફાઇલ ટ્રાન્સફર
સર્વસામાન્ય રીતે rsync -avz /source/dir/ user@target-ip:/target/dir/ આ રીતે ચલાવવામાં આવે છે. -a એટલે આર્કાઇવ મોડ જે પરવાનગીઓ, ટાઈમસ્ટેમ્પ અને સિમ્બોલિક લિંક જાળવે છે. -v ડીટેઇલ આઉટપુટ આપે છે. -z ટ્રાન્સફર વખતે ડેટા કમ્પ્રેસ કરે છે. ડિરેક્ટરીના અંતમાં સ્લેશનું મહત્વ છે: /source/dir/ લખવાથી ફોલ્ડરના અંદરના ફાઇલો જ કોપી થાય છે, જ્યારે /source/dir લખવા પર સમગ્ર ડિરેક્ટરી ટાર્ગેટમાં બને છે.
ઉદાહરણ તરીકે, જૂના સર્વર પર /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/.
જો root ઉપયોગ ન કરવો હોય તો ટાર્ગેટ પર રાઈટ રાઇટ ધરાવતો ખાસ યુઝર બનાવીને તેનો ઉપયોગ કરવો વધુ સુરક્ષિત રહેશે. જેમ કે deploy યુઝર અને સંબંધિત ફોલ્ડર ઓનર્સિપ સેટ કરવી. પ્રોડક્શનમાં સીધા rootથી કામ કરવું સરળ હોય પણ સુરક્ષાના દષ્ટિકોણથી સીમિત પરવાનગીવાળા યુઝરને પ્રાધાન્ય આપવું જોઈએ.
સલાહિયતવાળા સુરક્ષિત અને મજબૂત rsync વિકલ્પો
મોટા ફાઇલ ટ્રાન્સફરમાં ફક્ત મૂળભૂત કમાન્ડ પૂરતું ન હોઈ શકે. કનેક્શન તૂટવાનું જોખમ, અર્ધાંગ ફાઈલો, ખોટા ડિલીટ ઓપરેશન કે ધીમા નેટવર્ક માટે વધારાની વિકલ્પો વાપરવા જોઈએ. નીચેનું કમાન્ડ ઘણી સ્થિતિઓમાં મજબૂત શરૂઆત છે:
rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/dir/ user@target-ip:/target/dir/
આમાં -a આર્કાઇવ છે, -H હાર્ડ લિંક જાળવે છે, -A ACL પરવાનગીઓ સાચવે છે, -X એક્સટેન્ડેડ એટ્રિબ્યૂટ્સ રાખે છે. --numeric-ids યુઝર અને ગ્રુપ નામ નહીં પણ તેમની આઈડીઓ પરથી કામ કરે છે, જે જુદા સર્વરોમાં સહાયરૂપ થાય છે. --partial અર્ધાંગ ફાઇલો કાઢી ન નાખે. --progress ટ્રાન્સફર સ્ટેટ બતાવે છે. --append-verify ખાસ કરીને મોટા ફાઇલો માટે રાખે છે, જ્યાં ટ્રાન્સફર અટકવાથી પછીથી ચકાસીને ચાલુ રાખી શકાય.
દરેક પેરામીટર દરેક સિટ્યુએશનમાં જરૂરી ન હોઈ શકે. સામાન્ય વેબસાઈટ માટે -aHAX પૂરતું હોઈ શકે, જ્યારે ખાસ પરવાનગીઓ અને એટ્રિબ્યૂટ જરૂરી હોય ત્યારે વધુ વિકલ્પો જરૂરી બને. આથી પહેલા ટેસ્ટ ટ્રાન્સફર કરવું મહત્વનું છે.
જો SSH પોર્ટ અલગ હોય તો કમાન્ડ કેવી રીતે લખશો?
સુરક્ષાના કારણે SSH ડિફોલ્ટ 22 સિવાયના પોર્ટ પર ચાલે તે શક્ય છે. તે માટે rsync કમાન્ડમાં SSH પોર્ટ સ્પષ્ટ કરવો પડે છે. ઉદાહરણ: rsync -avz -e ssh -p 2222 /source/dir/ user@target-ip:/target/dir/ આ રીતે નહીં, કારણ કે -e અને -p અલગ-અલગ છે. યોગ્ય રીતે લખવું એ રીતે છે:
rsync -avz -e 'ssh -p 2222' /source/dir/ user@target-ip:/target/dir/
ટર્મિનલમાં સિંગલ કોટ્સ યોગ્ય રીતે લાગવા જોઈએ. SSH કી સાથે કનેક્શન હો ત્યારે વધુ આ રીતે લખો:
rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/dir/ user@target-ip:/target/dir/
આ રીત ઓટોમેશન અને ક્રોન બેઝ્ડ બેકઅપમાં વ્યાપક છે.
ટ્રાન્સફર પહેલા ટેસ્ટ: --dry-run વિકલ્પ
મોટા ડેટાનું ટ્રાન્સફર શરૂ કરતા પહેલા --dry-run ચલાવવું શ્રેષ્ઠ પ્રેક્ટિસ છે. આ પેરામીટર ફાઇલો કૉપિ કરતો નથી, ફક્ત કયા ફાઇલ્સ ટ્રાન્સફર થશે તે બતાવે છે. આથી ખોટા ડિરેક્ટરી, ટાર્ગેટ પાથ કે અનિચ્છિત ડિલીટ અટકાવી શકાય.
ટેસ્ટ કમાન્ડ ઉદાહરણ: rsync -avz --dry-run /var/www/site/ user@target-ip:/var/www/site/. આ આઉટપુટમાં ટ્રાન્સફર થનારા ફાઇલો અને ડિરેક્ટરીઝની યાદી મળે. જો --delete વાપરવો હોય તો dry-run ખાસ જરૂરી છે, કારણ કે --delete સોર્સમાં ન હોય તેવા ફાઇલ ટાર્ગેટમાંથી કાઢી નાખે છે. યોગ્ય રીતે વાપરવાનો અર્થ ટાર્ગેટને સોર્સનું aynા બનાવવો છે, ખોટા પાથમાં વાપરવાથી મોટી નુકસાન થાય.
સામાન્ય રીતે 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 બદલાવ દરમિયાન થાય છે. મોટા મીડિયા ધરાવતાં વર્ડપ્રેસ સાઇટ માટે આ ઘડતરની ડાઉનટાઈમ કલાકોથી મિનિટોમાં આવી શકે છે.
ડેટા પૂર્ણતા ચકાસણી
ટ્રાન્સફર પૂરો થયા પછી માત્ર કમાન્ડ પૂરું થયું તે પૂરતું નથી. ફાઇલ સંખ્યા, કદ અને મહત્વના ફાઇલ્સ ચકાસવા જોઈએ. સરળ ચકાસણી માટે સોર્સ અને ટાર્ગેટ પર du -sh ચલાવીને ડિરેક્ટરી કદ સરખાવો. પરંતુ ફાઇલ સિસ્ટમ બ્લોક ફર્કને કારણે આ સંપૂર્ણ સરખામણી ન હોઈ શકે. વધુ વિગતવાર માટે rsync ફરીથી તે જ વિકલ્પો સાથે ચલાવી શકો છો; જો કોઈ નવી ફાઇલો ટ્રાન્સફર થતી નથી તો આઉટપુટ ન્યૂનતમ રહેશે.
ચેકસમ ચકાસણી માટે rsync -avc --dry-run /source/dir/ user@target-ip:/target/dir/ ચલાવી શકાય છે. -c ફાઇલ્સને ટાઈમસ્ટેમ્પ અને કદ ઉપરાંત ચેકસમથી પણ સરખાવે છે. આ મોટા ડેટા પર CPU અને ડિસ્ક લોડ વધારી શકે છે, તેથી ધ્યાનથી વાપરવું જોઈએ. મહત્વના આર્કાઇવ, ડેટાબેઝ ડમ્પ અને ગ્રાહક દસ્તાવેજ માટે આ વધારે વિશ્વસનીયતા આપે છે.
જો વેબસાઈટ ટ્રાન્સફર કરી હોય તો એપ્લિકેશન લેવલ પર પણ ચકાસો. હોમપેજ, એડમિન પેનલ, ઈમેજ અપલોડ, પેમેન્ટ પેજ, સંપર્ક ફોર્મ અને એરર લોગ્સ તપાસવા આવશ્યક છે. ઇ-કોમર્સ સાઇટમાં ફક્ત ફાઇલો ટ્રાન્સફર પૂરતી નથી; પેમેન્ટ ઇન્ટિગ્રેશન અને ક્રોન ટાસ્ક્સ પણ નવી સર્વર પર ચકાસવા જોઈએ.
સામાન્ય ભૂલો અને સમાધાન
Permission denied ત્રુટિ
આ ત્રુટિ સામાન્ય રીતે SSH યુઝર પરમિશન, ટાર્ગેટ ડિરેક્ટરી પર લખવાનો અધિકાર કે કી ઓથેન્ટિકેશન ખોટા હોઈ થાય છે. પહેલા સામાન્ય SSH કનેક્શન ચકાસો. જો તે ચાલે તો ટાર્ગેટ ડિરેક્ટરીમાં ફાઇલ બનાવવાની કોશિશ કરો. જરૂર પડે તો chown વડે યોગ્ય માલિકી સેટ કરો અથવા sudo આધારિત યોજના બનાવો.
No space left on device ત્રુટિ
ટાર્ગેટ ડિસ્ક પૂરતો ખાલી ન હોય તો ટ્રાન્સફર અટકે. df -h વડે ડિસ્ક સ્પેસ તપાસો. ક્યારેક મુખ્ય ડિસ્ક ભરાયો ન હોય પરંતુ /tmp અથવા અન્ય માઉન્ટ પોઇન્ટ ભરાયેલો હોય શકે છે. મોટા ટ્રાન્સફરમાં લોગ ફાઇલો, જૂના બેકઅપ અને કેશ સાફ કરી શકાય. લાંબા ગાળે ડિસ્ક વધારવી કે વધુ ક્ષમતા ધરાવતો VPS લેવું જરૂરી છે.
Connection reset અથવા Broken pipe ત્રુટિ
લાંબા ટ્રાન્સફરમાં નેટવર્ક તૂટવા શક્ય છે. જો --partial અને --append-verify વાપરવામાં આવ્યા હોય તો કમાન્ડ ફરીથી ચલાવીને અટકેલી જગ્યેથી ચાલુ રાખી શકાય. SSH keepalive સેટિંગ્સ પણ મદદરૂપ થાય છે. ક્લાયન્ટ પર ServerAliveInterval 60 સેકન્ડ રાખવાથી કનેક્શન સમયસર જાળવી શકાય.
ટ્રાન્સફર ધીમો હોવો
ધીમું ટ્રાન્સફર ફાઇલ સંખ્યા, ડિસ્ક I/O લિમિટ, સંકોચન લોડ કે નેટવર્ક ક્ષમતા પર નિર્ભર કરે છે. ઘણા નાના ફાઇલ હોય તો પહેલા tar આર્કાઇવ બનાવીને ટ્રાન્સફર કરવું ઝડપ વધારી શકે છે, પણ એ રીતે rsyncનો ફાઈલ-બેઝ્ડ બદલાવ ટ્રેક કરવાનો ફાયદો ઓછો થાય. મોટા અને પહેલેથી જ સંકોચિત ફાઇલોમાં -z દૂર કરીને ટેસ્ટ કરો. iotop, htop અને iftop જેવા ટૂલ્સ વડે CPU, ડિસ્ક કે નેટવર્ક બોટલનેક શોધો.
સુરક્ષાના શ્રેષ્ઠ અભ્યાસ
સર્વરો વચ્ચે ફાઇલ ટ્રાન્સફર દરમિયાન સુરક્ષા અવગણવી નહી. ખાસ કરીને root એક્સેસ, SSH કી અને બેકઅપ ફાઇલો ખાસ ધ્યાનમાં લેવી જોઈએ. પાસવર્ડથી વધુ SSH કી આધારિત લૉગિન કરવું સલામત છે. કી ફાઈલોની પરવાનગી કડક રાખવી, ખાનગી કી શેર ન કરવી અને શક્ય હોય તો પાસફ્રેઝ સાથે સુરક્ષિત કરવી જોઈએ.
ટ્રાન્સફર માટે ટemporરી યુઝર બનાવીને ફક્ત જરૂરી ડિરેક્ટરીઝ માટે એક્સેસ આપવો યોગ્ય રીત છે. ટ્રાન્સફર પૂરો થયા પછી તે યુઝરની પરવાનગી દૂર કે ખાતું ડિસેબલ કરી શકાય. SSH એક્સેસ નિશ્ચિત IP સુધી મર્યાદિત કરવી saldırı જોખમ ઘટાડે છે. ફાયરવોલ નિયમો, Fail2ban અને OpenSSH અપડેટ્સ નિયમિત જાળવો.
ડેટાબેઝ ડમ્પ, ગ્રાહક દસ્તાવેજો કે ખાનગી માહિતી ધરાવતા આર્કાઇવો ટ્રાન્સફર પછી સોર્સ અને ટાર્ગેટ બંને જગ્યાએ અનાવશ્યક ટેમ્પ ફાઇલો સાફ કરવી. વેબ રુટમાં .sql, .zip અથવા .tar જેવા બેકઅપ ફાઇલો મુકવાં જોખમી છે. શક્ય હોય તો આ ફાઇલો વેબથી ઍક્સેસ ન થતી ડિરેક્ટરીમાં રાખો કે ટ્રાન્સફર પૂરો થઈ ગયા પછી ડિલીટ કરો.
સ્વચાલિત બેકઅપ માટે rsync નો ઉપયોગ
rsync માત્ર એક વાર માટે નહીં, નિયમિત બેકઅપ માટે પણ ઉપયોગી છે. દૈનિક બેકઅપ માટે क्रોનજોબ બનાવી શકાય છે જે SSH કીથી પાસવર્ડ વિના સુરક્ષિત કનેક્શન બનાવે છે, ફક્ત બદલાયેલા ફાઇલો જ મોકલે છે અને બૅન્ડવિડ્થ મર્યાદા પણ લગાડી શકે છે.
ઉદાહરણ: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. આ કમાન્ડ ટાર્ગેટ ડિરેક્ટરીને સોર્સ સાથે સમકક્ષ બનાવે છે. --delete વાપરતી વખતે ધ્યાન રાખવું જોઈએ કારણ કે સોર્સમાંથી ડિલીટ થયેલી ફાઇલો ટાર્ગેટમાંથી પણ કાઢી નાખે છે. ક્રિટિકલ બેકઅપમાં snapshot, ડેઇલી ફોલ્ડર અથવા વર્ઝનિંગ આધારિત સોલ્યુશન્સ શ્રેષ્ઠ રહે છે.
હોસ્ટિંગ ઓપરેશન્સમાં 3-2-1 બેકઅપ નિયમ અગત્યનો છે: ડેટાની ઓછામાં ઓછા 3 નકલ, 2 અલગ માધ્યમમાં અને 1 નકલ વિભિન્ન સ્થાન પર રાખવી. rsync આ નકલ બનાવવાની પ્રક્રિયા સરળ બનાવે છે. વધુ વિસ્તૃત ઇન્ફ્રાસ્ટ્રક્ચર માટે બેકઅપ ઉકલો અને કોર્પોરેટ હોસ્ટિંગ સેવાઓ સાથે યોજના બનાવી શકો છો.
અંતિમ ચેકલિસ્ટ
મોટા ફાઇલ ટ્રાન્સફર શરુ કરતાં પહેલા નીચેની ટૂંકી યાદી તપાસો, આ ભૂલોના જોખમને ઘટાડે છે. ખાસ કરીને પ્રોડક્શનમાં આ નિયમિત અભ્યાસ હોવો જોઈએ.
- સોર્સ અને ટાર્ગેટ સર્વરમાં rsync ઈન્સ્ટોલ છે?
- SSH કનેક્શન યોગ્ય યુઝર અને પોર્ટ સાથે ચકાસ્યું છે?
- ટાર્ગેટ સર્વરમાં પૂરતો ડિસ્ક સ્પેસ છે?
- પ્રથમ --dry-run સાથે ટેસ્ટ કર્યું છે?
- લાઇવ સાઇટ માટે મેન્ટનન્સ મોડ અને છેલ્લું સમકક્ષ ટ્રાન્સફર પ્લાન કર્યું છે?
- --delete વાપરવાથી પહેલા ટાર્ગેટ પાથ ચોક્કસ કર્યો છે?
- ટ્રાન્સફર પછી ફાઇલ સાઈઝ, પરવાનગીઓ અને એપ્લિકેશન ટેસ્ટ થશે?
- ટેમ્પ બેકઅપ અને ડમ્પ ફાઇલો સુરક્ષિત રીતે સાફ થશે?
આ ચેકલિસ્ટ જો સરળ લાગે પણ વાસ્તવમાં સૌથી વધુ થતા સમસ્યાઓ ખોટા ડિરેક્ટરી, પરવાનગી ન હોવી, ખાલી ડિસ્ક ન હોવી અને DNS પ્લાન ન હોવાના કારણે થાય છે. સજાગ rsync પ્રક્રિયા સમય બચાવે છે અને પ્રોબ્લેમ ફિક્સિંગ સરળ બનાવે છે.
સામાન્ય પ્રશ્નો
SSH દ્વારા rsync કનેક્શન તૂટે તો ટ્રાન્સફર ફરીથી શરૂ થશે?
સાચા વિકલ્પો સાથે ટ્રાન્સફર ફરીથી શરૂ નહીં થાય. --partial અને --append-verify વિકલ્પો અર્ધાંગ મોટા ફાઇલ્સ બચાવે છે અને ફરીથી શરૂ કરવાથી ત્યાંથી આગળ વધે છે. તદ્દાપિ મહત્વપૂર્ણ ટ્રાન્સફરમાં ફરીથી શરૂ કરતા પહેલા ટાર્ગેટમાં જથ્થો અને અર્ધાંગ ફાઇલ ચકાસો.
rsync વડે ડેટાબેઝ સીધા ટ્રાન્સફર થશે?
rsync ફાઇલ ટ્રાન્સફર કરે છે; ડેટાબેઝ ચાલતી સ્થિતિમાં સીધા નકલ કરવી યોગ્ય નથી. MySQL અથવા MariaDB માટે mysqldump કે ફિઝિકલ બેકઅપ ટૂલ્સ વાપરીને બેકઅપ બનાવી rsync વડે ટ્રાન્સફર કરવી જોઈએ. લાઇવ સિસ્ટમમાં ડેટા કન્સિસ્ટન્સી માટે મેન્ટનન્સ મોડ કે રેપ્લિકેશન સ્ટ્રેટેજી જરૂરી છે.
rsync માટે બંને સર્વરોમાં root એક્સેસ જોઈએ?
root એક્સેસ જરૂરી નથી. ટાર્ગેટ ફોલ્ડર માટે લખવાની પરવાનગી ધરાવતો યુઝર પૂરતો છે. જો ફાઇલ માલિકી, સિસ્ટમ ડિરેક્ટરીઝ, ACL કે ખાસ પરવાનગીઓ જાળવવી હોય તો વધુ અધિકારો જરૂરી થઈ શકે. સુરક્ષાના દૃષ્ટિકોણથી સીમિત અધિકારવાળા યુઝરથી કામ કરવું સારું.
--delete સુરક્ષિત છે?
--delete યોગ્ય રીતે વાપરવાથી ટાર્ગેટને સોર્સનું aynા બનાવી શકે છે, પણ ખોટા પાથ પર ઉપયોગ કરવાથી ફાઇલ ખોવાઈ શકે છે. આ માટે હંમેશા પહેલા --dry-run સાથે પરીક્ષણ કરવું અને સોર્સ-ટાર્ગેટ પાથ બરાબર ચકાસવાનું જરૂરી છે.
મોટા ફાઇલ માટે rsync કે scp વધુ સારું?
સિંગલ કૉપીઓ માટે scp પૂરતું છે, પણ મોટા, ઘણાબધા અને વારંવાર સમકક્ષ બનાવવા rsync વધુ શ્રેષ્ઠ છે. કારણ કે તે બદલાયેલ ડેટા ઓળખી શકે છે, અર્ધાંગ ટ્રાન્સફર ચાલુ રાખી શકે છે, બૅન્ડવિડ્થ મર્યાદિત કરી શકે છે અને ટેસ્ટ મોડ આપે છે.
સારાંશ અને આગળનું પગલું
SSH મારફતે rsync કમાન્ડથી બે સર્વરો વચ્ચે મોટા ફાઇલો ઝડપી, સુરક્ષિત અને વ્યવસ્થિત રીતે ટ્રાન્સફર કરી શકાય છે. યોગ્ય વિકલ્પો સાથે કનેક્શન તૂટવાથી બચી શકાય છે, ફક્ત બદલાયેલા ફાઇલો જ મોકલાતા સમય બચે છે અને લાઇવ સાઇટ ટ્રાન્સફર દરમ્યાન ડાઉનટાઇમ ઓછો થાય છે. શ્રેષ્ઠ પરિણામ માટે પહેલા SSH અને ડિસ્ક ચકાસણા કરી, --dry-run થી ટેસ્ટ કરીને, પછી મુખ્ય ટ્રાન્સફર આયોજનબદ્ધ રીતે ચલાવો.
જો તમે નવી સર્વર પર શિફ્ટ થવા માંગતા હોવ, વધુ સ્ટોરેજ કે ઝડપી હોસ્ટિંગ ઇન્ફ્રાસ્ટ્રક્ચર માટે Hostragons ના વિકલ્પો જુઓ અને VPS, હોસ્ટિંગ, ડોમેન અને SSL સાથે તમારી ટ્રાન્સફર પ્રક્રિયા વધુ સુરક્ષિત બનાવો. નાના ટેસ્ટથી શરૂ કરો, માપો અને છેલ્લી સમકક્ષતા યોજના અનુસાર પૂર્ણ કરો જેથી શ્રેષ્ઠ અને નિઃશંક માઈગ્રેશન થાય.