rclone के साथ Bash में केवल-कॉपी क्लाउड ट्रांसफ़र

संक्षिप्त उत्तर

बड़े या बिना निगरानी वाले माइग्रेशन के लिए FileArk अधिक सरल प्रबंधित विकल्प है: यह ट्रांसफ़र ऑनलाइन चलाता है, इसे कई टेराबाइट के वर्कलोड पर परखा गया है और यह पूरा होने से पहले हर परिणाम की जाँच करता है। जो ऑपरेटर डेटा पाथ को शेल से नियंत्रित करना चाहते हैं, उनके लिए MIT-लाइसेंस वाला यह Bash रैपर स्थानीय स्टेजिंग के माध्यम से सीमित बैच कॉपी करता है, दोनों चरणों का बाइट-दर-बाइट सत्यापन करता है और स्रोत फ़ाइलों को कभी नहीं हटाता।

हर प्रोवाइडर क्लाइंट को फिर से बनाने के बजाय rclone के लिए रैपर क्यों बनाएँ

rclone किसी शेल वर्कफ़्लो को परिपक्व प्रोवाइडर एब्स्ट्रैक्शन, OAuth कॉन्फ़िगरेशन, पेजिनेशन, पुनः प्रयास का व्यवहार, फिर से शुरू किए जा सकने वाले ट्रांसफ़र, समवर्ती संचालन के नियंत्रण, इन्वेंटरी कमांड और सत्यापन कमांड उपलब्ध कराता है। इसलिए रैपर माइग्रेशन के अपरिवर्तनीय नियमों पर ध्यान दे सकता है: केवल कॉपी करने वाले वर्ब, सीमित स्टेजिंग, क्षमता रिज़र्व, नियतात्मक फ़ाइल सूचियाँ और टिकाऊ प्रगति रिकॉर्ड।

इससे काम स्वचालित नहीं हो जाता। रिमोट कॉन्फ़िगरेशन, टोकन सुरक्षा, नेटवर्क की उपलब्धता, प्रोसेस की निगरानी, स्थानीय डिस्क, लॉग, प्रोवाइडर सीमाएँ, विफल ऑब्जेक्ट की समीक्षा और डेस्टिनेशन की स्वीकृति की ज़िम्मेदारी अब भी ऑपरेटर की होती है। FileArk उन उपयोगकर्ताओं के लिए है जो इस प्रक्रिया को अपने वर्कस्टेशन या सर्वर के बजाय प्रबंधित ऑनलाइन वर्कफ़्लो के रूप में संचालित कराना चाहते हैं।

स्क्रिप्ट स्पष्ट रूप से कभी भी rclone move, sync, delete, purge या rmdirs नहीं चलाती। यह खोज के लिए lsf और about, हर चरण के लिए copy और सभी बाइट के सत्यापन के लिए check --download का उपयोग करती है। केवल स्थानीय स्टेजिंग डायरेक्टरी से सत्यापित फ़ाइल हटाई जाती है।

Bash संस्करण और MIT लाइसेंस डाउनलोड करें

नेटवर्क के बिना ऑपरेटर डेमो चलाएँ

डेमो को rclone या jq इंस्टॉल होने से पहले भी सुरक्षित रूप से चलाया जा सकता है, क्योंकि आर्ग्युमेंट पार्सिंग डिपेंडेंसी जाँच से पहले ही समाप्त हो जाती है। आउटपुट में प्रतिबंधित विनाशकारी ऑपरेशनों के नाम दिए जाते हैं, दोनों क्षमता रिज़र्व दिखाए जाते हैं और अंत में स्रोत से हटाई गई फ़ाइलों की संख्या दिखाई जाती है।

chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

ऑपरेटर डिपेंडेंसी इंस्टॉल और कॉन्फ़िगर करें

आधिकारिक निर्देशों का उपयोग करके rclone का नवीनतम रिलीज़ इंस्टॉल करें और अपने ऑपरेटिंग सिस्टम के पैकेज मैनेजर से jq इंस्टॉल करें। Bash 4 या उसके बाद का संस्करण आवश्यक है, क्योंकि रैपर सख़्त त्रुटि प्रबंधन और आधुनिक कंडीशनल एक्सप्रेशन का उपयोग करता है।

rclone config चलाएँ और अलग-अलग नाम वाले दो रिमोट बनाएँ, जैसे onedrive: और gdrive:। जब नीति या दर सीमाओं के कारण समर्पित OAuth ऐप्लिकेशन आवश्यक हों, तो अपना प्रोवाइडर क्लाइंट ID और सीक्रेट दर्ज करें। rclone अपने कॉन्फ़िगरेशन फ़ाइल में OAuth टोकन संग्रहीत करता है; उस फ़ाइल को सख्त अनुमतियों से सुरक्षित रखें और उसे कभी भी स्क्रिप्ट के साथ बंडल न करें।

रैपर चलाने से पहले केवल-पढ़ने वाली लिस्टिंग और कोटा कमांड से हर रिमोट की पुष्टि करें। जब दायरे में केवल कोई सबट्री हो, तो onedrive:Department/Archive जैसे पाथ का उपयोग करें।

rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

बाइट ट्रांसफ़र करने से पहले एक नियतात्मक इन्वेंटरी फ़्रीज़ करें

रैपर स्पष्ट टैब सेपरेटर और sp फ़ॉर्मैट के साथ rclone lsf का रिकर्सिव रूप से उपयोग करता है, जिससे पहले साइज़ और फिर पाथ मिलता है। यह पुष्टि करता है कि हर साइज़ संख्यात्मक और हर पाथ रिलेटिव है, फिर सत्यापित चेकपॉइंट में पहले से मौजूद पाथ को बाहर कर देता है।

Bash संस्करण उन फ़ाइल नामों को अस्वीकार करता है जिनमें टैब, कैरिज रिटर्न या नई पंक्ति होती है, क्योंकि नई पंक्ति से अलग की गई --files-from-raw सूचियाँ उन्हें बिना अस्पष्टता के प्रस्तुत नहीं कर सकतीं। ऐसे नाम मौजूद होने पर Python संस्करण या खास तौर पर बनाया गया इन्वेंटरी फ़ॉर्मैट इस्तेमाल करें।

पाथ चेकपॉइंट को जानबूझकर सरल और निरीक्षण योग्य रखा गया है। यह मानकर चलता है कि रन के दौरान स्रोत पाथ स्थिर रहेंगे। संभव हो तो स्रोत पर लिखने की क्रिया रोक दें; या समवर्ती बदलाव अपेक्षित हों, तो इन्वेंटरी फिर से बनाकर उसका मिलान करें।

rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

बैच द्वारा रिज़र्व की खपत शुरू होने से पहले विफल करें

स्थानीय खाली बाइट स्टेजिंग फ़ाइल सिस्टम पर df से मिलते हैं। डेस्टिनेशन के खाली बाइट rclone about --json से मिलते हैं: उपलब्ध होने पर स्क्रिप्ट free का उपयोग करती है, अन्यथा total में से used घटाती है। यह काम शुरू करने से पहले लंबित बाइट की कुल संख्या जाँचती है और हर बैच से पहले स्थानीय तथा डेस्टिनेशन क्षमता की फिर से जाँच करती है।

कुछ प्रदाता या खाता प्रकार rclone के माध्यम से निश्चित कोटा प्रकाशित नहीं करते। रैपर इस सीमा की जानकारी देता है और प्रदाता द्वारा लागू पाबंदियों के तहत जारी रहता है। इसे निगरानी की आवश्यकता मानें, पर्याप्त जगह का प्रमाण नहीं।

बैच सीमा किसी एक ऑब्जेक्ट के लिए कठोर अधिकतम सीमा नहीं है। कॉन्फ़िगर किए गए बैच से बड़ी कोई एक फ़ाइल अपना अलग बैच बना सकती है, इसलिए स्थानीय खाली जगह सबसे बड़ी फ़ाइल और रिज़र्व—दोनों के लिए पर्याप्त होनी चाहिए। डेस्टिनेशन का पूर्ण सत्यापन वहाँ से बाइट पढ़ता है, लेकिन rclone संस्करण में दूसरी स्थानीय कॉपी नहीं रखता।

लोकल स्टेजिंग सीमा के दोनों ओर सत्यापन करें

हर बैच दो स्वतंत्र चरणों से गुजरता है। पहले rclone चुने गए स्रोत पाथ को --ignore-existing के साथ स्थानीय स्टेजिंग में कॉपी करता है, फिर check --download दोनों ओर का डेटा पढ़कर वास्तविक सामग्री की तुलना करता है। इसके बाद rclone स्टेज की गई फ़ाइलों को डेस्टिनेशन में कॉपी करता है और सभी बाइट की वही जाँच दोहराता है।

--ignore-existing बाधित रन को गैर-विनाशकारी बनाता है: किसी मौजूदा ऑब्जेक्ट को ओवरराइट नहीं किया जाता। पाथ को चेकपॉइंट में जोड़ने से पहले सत्यापन का पास होना फिर भी आवश्यक है। यदि डेस्टिनेशन पर मौजूद ऑब्जेक्ट अलग है, तो rclone check विफल हो जाता है और Bash की सख्त त्रुटि प्रबंधन प्रक्रिया रन को रोक देती है।

--download का उपयोग धीमा होता है और प्रदाता के इग्रेस/रीड ऑपरेशन की खपत करता है, लेकिन इससे केवल इस बात पर निर्भर नहीं रहना पड़ता कि दोनों प्रदाता कोई साझा हैश एल्गोरिदम उपलब्ध कराते हैं या नहीं। यह कमांड किसी भी ओर कोई बदलाव नहीं करता।

rclone copy "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" --one-way --download

rclone copy "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" --one-way --download

सीमित स्टेजिंग के साथ OneDrive से Google Drive ट्रांसफ़र चलाएँ

इस उदाहरण में स्थानीय डिस्क का 15 GiB हिस्सा अछूता रखा जाता है, Google Drive में 10 GiB खाली रखा जाता है, सामान्य बैच को अधिकतम 8 GiB या 200 फ़ाइलों तक सीमित किया जाता है और चार समवर्ती ट्रांसफ़र उपयोग किए जाते हैं। डेस्टिनेशन की सामग्री तारीख वाले एक नए फ़ोल्डर में लिखी जाती है।

पहले --dry-run का उपयोग करें। यह डाउनलोड या अपलोड किए बिना स्रोत की इन्वेंट्री और गंतव्य कोटा की प्रीफ़्लाइट जाँच करता है। रैपर सभी लंबित बाइट दिखाता है, जिनका पहले वास्तविक बैच से पहले आपके माइग्रेशन के दायरे से मिलान किया जाना चाहिए।

./fileark-cloud-transfer.sh \
  --source onedrive: \
  --destination gdrive: \
  --destination-folder "OneDrive archive 2026-07-25" \
  --staging-dir /srv/fileark-staging \
  --state-file ./onedrive-to-google-verified.txt \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --transfers 4 \
  --checkers 8 \
  --dry-run

# Remove only --dry-run after reviewing the preflight.

स्थिति का दोबारा उपयोग किए बिना दिशा उलटें

रैपर प्रोवाइडर-निरपेक्ष है, क्योंकि रिमोट अडैप्टर rclone संभालता है। Google Drive को OneDrive में कॉपी करने के लिए रिमोट आर्ग्युमेंट की अदला-बदली करें और उस रन के लिए नया डेस्टिनेशन फ़ोल्डर, स्टेजिंग पाथ और चेकपॉइंट फ़ाइल दें।

Google के मूल Docs, Sheets, Slides और अन्य वर्चुअल फ़ॉर्मैट के लिए rclone एक्सपोर्ट कॉन्फ़िगरेशन और सावधानीपूर्वक समीक्षा की आवश्यकता होती है। किसी परीक्षण सेट से एक्सपोर्ट किए गए एक्सटेंशन और कन्वर्ज़न के व्यवहार की पुष्टि करें। शेल कॉपी Google का सहयोग इतिहास, शॉर्टकट, अनुमतियाँ या Microsoft-विशिष्ट मेटाडेटा सुरक्षित नहीं रखती।

./fileark-cloud-transfer.sh \
  --source gdrive: \
  --destination onedrive: \
  --destination-folder "Google archive 2026-07-25" \
  --staging-dir /srv/google-staging \
  --state-file ./google-to-onedrive-verified.txt \
  --batch-gib 8 \
  --local-reserve-gib 15

डेस्टिनेशन सत्यापन के बाद ही चेकपॉइंट बनाएँ

डेस्टिनेशन जाँच सफलतापूर्वक पूरी होने के बाद रैपर हर रिलेटिव पाथ को सादे टेक्स्ट वाले चेकपॉइंट में जोड़ देता है। फिर वह उस फ़ाइल को स्थानीय स्टेजिंग से हटाता है और खाली स्थानीय डायरेक्टरी हटा देता है। स्रोत रिमोट अछूता रहता है।

रन के दौरान चेकपॉइंट में केवल नई प्रविष्टियाँ जोड़ी जाती हैं और मानक टूल से इसका ऑडिट करना आसान है। इसे कमांड लाइन, rclone संस्करण, कॉन्फ़िगरेशन फ़िंगरप्रिंट, इन्वेंटरी, लॉग, टाइमस्टैम्प और स्वीकृति नोट्स के साथ सुरक्षित रखें। किसी विफलता को छिपाने के लिए इसे तब तक संपादित न करें, जब तक डेस्टिनेशन फ़ाइल का स्वतंत्र रूप से सत्यापन न किया गया हो।

केवल पाथ पर आधारित चेकपॉइंट ऐसे स्रोत ऑब्जेक्ट का पता नहीं लगा सकता जिसकी सामग्री पाथ बदले बिना बदल जाती है। परिवर्तनशील डेटासेट के लिए, लिखने की कार्रवाइयाँ रोकें, प्रदाता ID और संशोधन मेटाडेटा अलग से कैप्चर करें या Python संस्करण का अधिक सख़्त ID-और-आकार चेकपॉइंट इस्तेमाल करें। विनियमित या सहयोगात्मक माइग्रेशन के लिए स्पष्ट परिवर्तन नियंत्रण वाले प्रबंधित वर्कफ़्लो का उपयोग करें।

हर गैर-शून्य एग्ज़िट को अनसुलझा बैच मानें

• किसी कमांड, पाइपलाइन या सेट न किए गए वेरिएबल के विफल होने पर स्ट्रिक्ट मोड बाहर निकल जाता है; अस्थायी इन्वेंटरी डायरेक्टरी अपने-आप हटा दी जाती है।
• rclone अस्थायी ट्रांसफ़र विफलताओं पर पुनः प्रयास करता है, लेकिन लगातार बनी रहने वाली अनुमति, कोटा, नेटवर्क, विरोध या अखंडता संबंधी त्रुटियाँ बैच को रोक देती हैं।
• चेकपॉइंट में शामिल न की गई स्टेज्ड फ़ाइलें निरीक्षण के लिए उपलब्ध रहती हैं और समान कमांड से दोबारा रन करने पर उनके बाइट की जाँच से पहले --ignore-existing का उपयोग होता है।
• गंतव्य की अलग सामग्री वाली फ़ाइल को कभी ओवरराइट नहीं किया जाता। टकराव का समाधान करें या एक साफ़ गंतव्य रूट चुनें।
• विफल कॉपी को rclone sync या move में न बदलें। उन कमांड में हटाने के नियम अलग होते हैं।
• डेस्टिनेशन की मैन्युअल स्वीकृति पूरी होने तक लॉग और चेकपॉइंट सुरक्षित रखें।

डेटा प्लेन बनने वाले होस्ट को सुरक्षित करें

स्टेजिंग होस्ट में अस्थायी रूप से स्रोत डेटा की पढ़ने योग्य प्रतियाँ और OAuth रिफ़्रेश टोकन रहते हैं। फ़ुल-डिस्क एन्क्रिप्शन, सख़्त फ़ाइल अनुमतियों, समर्पित ऑपरेटिंग-सिस्टम खाते, अपडेट की गई डिपेंडेंसी, नियंत्रित एडमिनिस्ट्रेटर एक्सेस और ऐसी एन्क्रिप्टेड बैकअप नीति का उपयोग करें जो स्टेजिंग सामग्री को अनपेक्षित रूप से बनाए न रखे।

कमांड लाइन में सीक्रेट देने से बचें, क्योंकि प्रोसेस सूचियाँ और शेल हिस्ट्री उन्हें उजागर कर सकती हैं। rclone का सुरक्षित कॉन्फ़िगरेशन संग्रहीत टोकन को अस्पष्ट कर सकता है, लेकिन यह होस्ट सुरक्षा का विकल्प नहीं है। माइग्रेशन स्वीकार हो जाने के बाद अपनी रिटेंशन नीति के अनुसार टोकन सामग्री और स्टेजिंग के बचे हुए डेटा को हटा दें।

प्रोवाइडर ऑडिट लॉग, नेटवर्क इग्रेस, डिस्क की स्थिति, inode की उपलब्धता, प्रोसेस की स्थिति और rclone आउटपुट पर नज़र रखें। केवल टर्मिनल खुला छोड़ देना प्रोसेस की निगरानी नहीं है; स्वीकृत सर्विस मैनेजर या टर्मिनल मल्टीप्लेक्सर का उपयोग करें और लॉग को टिकाऊ बनाएँ।

माइग्रेशन को केवल हरे कमांड से नहीं, प्रमाण के साथ पूरा करें

• फ़्रीज़ की गई इन्वेंटरी, सटीक कमांड, स्क्रिप्ट चेकसम, rclone संस्करण, रिमोट कॉन्फ़िगरेशन फ़िंगरप्रिंट और सत्यापित चेकपॉइंट को आर्काइव करें।
• फ़ाइलों की संख्या और ज्ञात बाइट का मिलान केवल ड्राइव के कुल स्तर पर नहीं, बल्कि फ़ोल्डर के अनुसार करें।
• जोखिम के आधार पर बड़ी, छोटी, पुरानी, नई, Unicode वाली, गहराई से नेस्ट की गई, आर्काइव की गई और कन्वर्ट की गई फ़ाइलों का नमूना खोलकर देखें।
• प्रतिनिधि उपयोगकर्ता खातों से डेस्टिनेशन की पहुँच जाँचें और आवश्यक शेयरिंग अलग से फिर बनाएँ।
• छोड़े गए पैकेज, शॉर्टकट, लिंक, नेटिव दस्तावेज़, विरोध और प्रोवाइडर चेतावनियों की समीक्षा करें।
• स्रोत को बनाए रखने की एक ओवरलैप अवधि रखें और बाद में डेटा बनाए रखने या हटाने का कोई भी निर्णय लेने से पहले मालिक की स्पष्ट स्वीकृति प्राप्त करें।

अक्सर पूछे जाने वाले सवाल

Bash स्क्रिप्ट sync के बजाय rclone copy का उपयोग क्यों करती है?

कॉपी करने से स्रोत ऑब्जेक्ट नहीं हटते और डेस्टिनेशन के वे ऑब्जेक्ट भी नहीं हटते जो स्रोत में मौजूद नहीं हैं। सिंक के मिलान और हटाने के नियम अलग होते हैं, इसलिए उसे जानबूझकर इस वर्कफ़्लो से बाहर रखा गया है।

क्या rclone check --download किसी भी क्लाउड में बदलाव करता है?

नहीं। यह फ़ाइल की सामग्री पढ़कर उसकी तुलना करता है। स्क्रिप्ट हर कॉपी चरण के बाद इसका उपयोग करती है, ताकि किसी पाथ को तभी चेकपॉइंट किया जाए जब गंतव्य के बाइट स्टेज किए गए बाइट से मेल खाते हों।

यदि डेस्टिनेशन में कोई फ़ाइल पहले से मौजूद हो, तो क्या होता है?

कॉपी में --ignore-existing का उपयोग होता है और उसके बाद सभी बाइट का सत्यापन किया जाता है। समान ऑब्जेक्ट जाँच में पास हो सकता है; अलग ऑब्जेक्ट होने पर जाँच विफल हो जाती है। स्क्रिप्ट विरोध वाली फ़ाइल को कभी ओवरराइट नहीं करती।

क्या स्क्रिप्ट एक बैच से बड़ी फ़ाइलें संभाल सकती है?

हाँ। एक बहुत बड़ी फ़ाइल अपने आप में अलग बैच बन जाती है। स्टेजिंग फ़ाइल सिस्टम में उस फ़ाइल और कॉन्फ़िगर किए गए लोकल रिज़र्व, दोनों के लिए पर्याप्त जगह होनी चाहिए।

क्या यह अनुमतियाँ, संस्करण या क्लाउड-मूल सहयोग डेटा माइग्रेट करता है?

नहीं। यह rclone के माध्यम से फ़ाइल की सामग्री और पाथ कॉपी करता है। एक्सेस नियंत्रण, संस्करण, लेबल, टिप्पणियाँ, शॉर्टकट, लिंक, प्रतिधारण नियम और प्रदाता-मूल व्यवहार के लिए अलग से योजना और सत्यापन आवश्यक हैं।

इस गाइड के लिए उपयोग किए गए आधिकारिक संसाधन

• Google Workspace शिक्षण केंद्र: OneDrive से Google Drive पर स्विच करें
• Google Drive सहायता: स्टोरेज और फ़ाइलों का व्यवहार
• Microsoft सहायता: OneDrive पर फ़ाइलें अपलोड और सेव करें
• rclone copy कमांड संदर्भ
• rclone check और सभी बाइट का सत्यापन
• rclone lsf इन्वेंट्री फ़ॉर्मैट
• rclone about का कोटा आउटपुट