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 ایپلیکیشنز درکار ہوں تو اپنے فراہم کنندہ کی client ID اور secret درج کریں۔ 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

بائٹس منتقل کرنے سے پہلے ایک قطعی انوینٹری منجمد کریں

ریپر rclone lsf کو صراحتاً مقررہ ٹیب سیپریٹر اور sp فارمیٹ کے ساتھ بار بار ذیلی سطحوں تک استعمال کرتا ہے، جس سے پہلے سائز اور پھر پاتھ حاصل ہوتا ہے۔ یہ تصدیق کرتا ہے کہ ہر سائز عددی اور ہر پاتھ نسبتی ہے، پھر ان پاتھز کو خارج کر دیتا ہے جو پہلے ہی تصدیق شدہ چیک پوائنٹ میں موجود ہوں۔

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 ورژن، کنفیگریشن فنگر پرنٹ، انوینٹری، لاگز، ٹائم اسٹیمپس اور منظوری کے نوٹس کے ساتھ محفوظ رکھیں۔ کسی ناکامی کو چھپانے کے لیے اس میں ترمیم نہ کریں، الا یہ کہ منزل کی فائل کی آزادانہ طور پر تصدیق کی گئی ہو۔

صرف راستے پر مبنی چیک پوائنٹ ایسے ماخذ آبجیکٹ کا پتا نہیں لگا سکتا جس کا راستہ بدلے بغیر مواد تبدیل ہو جائے۔ قابلِ تغیر ڈیٹا سیٹس کے لیے تحریری کارروائیاں روکیں، فراہم کنندہ کی IDs اور ترمیمی میٹا ڈیٹا علیحدہ محفوظ کریں، یا Python ایڈیشن کا زیادہ سخت ID اور سائز پر مبنی چیک پوائنٹ استعمال کریں۔ ضابطوں کے تابع یا اشتراکی منتقلیوں کے لیے واضح تبدیلی کنٹرول والا منظم ورک فلو استعمال کریں۔

ہر غیر صفر ایگزٹ کو غیر حل شدہ بیچ سمجھیں

• کسی کمانڈ، پائپ لائن یا غیر مقررہ ویری ایبل کی ناکامی پر سخت موڈ پروگرام بند کر دیتا ہے؛ عارضی انوینٹری ڈائریکٹری خودکار طور پر ہٹا دی جاتی ہے۔
• rclone عارضی طور پر ناکام منتقلیوں کی دوبارہ کوشش کرتا ہے، لیکن اجازت، کوٹے، نیٹ ورک، تصادم یا سالمیت کی مسلسل خرابیاں بیچ روک دیتی ہیں۔
• چیک پوائنٹ میں شامل نہ ہونے والی اسٹیج شدہ فائلیں معائنے کے لیے دستیاب رہتی ہیں، اور اسی طرح کا دوبارہ رن ان کی بائٹس جانچنے سے پہلے --ignore-existing استعمال کرتا ہے۔
• منزل پر موجود مختلف فائل کو کبھی اوور رائٹ نہیں کیا جاتا۔ تضاد حل کریں یا منزل کی نئی اور خالی روٹ منتخب کریں۔
• ناکام کاپی کو rclone sync یا move میں تبدیل نہ کریں۔ ان کمانڈز میں حذف کرنے کے اصول مختلف ہیں۔
• منزل کی دستی منظوری مکمل ہونے تک لاگز اور چیک پوائنٹ محفوظ رکھیں۔

ڈیٹا پلین بننے والے ہوسٹ کو محفوظ بنائیں

اسٹیجنگ ہوسٹ میں عارضی طور پر ماخذ ڈیٹا کی قابلِ مطالعہ نقول اور OAuth ریفریش ٹوکنز موجود ہوتے ہیں۔ مکمل ڈسک انکرپشن، سخت فائل اجازتیں، آپریٹنگ سسٹم کا مختص اکاؤنٹ، اپ ڈیٹ شدہ انحصارات، منتظم کی محدود رسائی، اور ایسی انکرپٹڈ بیک اپ پالیسی استعمال کریں جو اسٹیجنگ کے مواد کو غیر متوقع طور پر برقرار نہ رکھے۔

کمانڈ لائن میں خفیہ معلومات دینے سے گریز کریں، کیونکہ عمل کی فہرستیں اور شیل ہسٹری انہیں ظاہر کر سکتی ہیں۔ rclone کی محفوظ کنفیگریشن غیر استعمال حالت میں ٹوکنز کو غیر واضح کر سکتی ہے، مگر یہ میزبان نظام کی سکیورٹی کا متبادل نہیں۔ منتقلی کی منظوری کے بعد اپنی برقرار رکھنے کی پالیسی کے مطابق ٹوکن کا مواد اور اسٹیجنگ کی باقیات ہٹا دیں۔

فراہم کنندہ کے آڈٹ لاگز، نیٹ ورک ایگریس، ڈسک کی صحت، inode کی دستیابی، عمل کی حالت اور rclone آؤٹ پٹ کی نگرانی کریں۔ ٹرمینل کھلا چھوڑ دینا عمل کی نگرانی نہیں ہے؛ منظور شدہ سروس مینیجر یا ٹرمینل ملٹی پلیکسر استعمال کریں اور لاگز کو پائیدار بنائیں۔

منتقلی کو سبز کمانڈ نہیں، شواہد کے ساتھ مکمل کریں

• منجمد انوینٹری، عین کمانڈ، اسکرپٹ چیک سم، rclone ورژن، ریموٹ کنفیگریشن فنگر پرنٹ اور تصدیق شدہ چیک پوائنٹ آرکائیو کریں۔
• فائلوں کی تعداد اور معلوم بائٹس کو صرف پوری ڈرائیو کی سطح پر نہیں بلکہ ہر فولڈر کے لحاظ سے بھی ملائیں۔
• خطرے کی بنیاد پر بڑی، چھوٹی، پرانی، نئی، Unicode، گہرائی میں موجود، آرکائیو شدہ اور تبدیل شدہ دستاویزات کا نمونہ کھولیں۔
• نمائندہ صارف اکاؤنٹس سے منزل تک رسائی آزمائیں اور مطلوبہ شیئرنگ الگ سے دوبارہ بنائیں۔
• چھوڑے گئے پیکیجز، شارٹ کٹس، لنکس، مقامی نوعیت کی دستاویزات، تصادمات اور فراہم کنندہ کے انتباہات کا جائزہ لیں۔
• ماخذ کو کچھ مدت تک برقرار رکھیں اور بعد میں اسے محفوظ رکھنے یا حذف کرنے کے کسی بھی فیصلے سے پہلے مالک کی واضح منظوری حاصل کریں۔

اکثر پوچھے گئے سوالات

Bash اسکرپٹ میں rclone sync کے بجائے rclone copy کیوں استعمال کیا جاتا ہے؟

کاپی کرنے سے نہ تو ماخذ کے آبجیکٹس حذف ہوتے ہیں، نہ ہی منزل سے وہ آبجیکٹس ہٹتے ہیں جو ماخذ میں موجود نہیں۔ Sync میں مطابقت اور حذف کرنے کے مختلف اصول ہوتے ہیں، اس لیے اسے جان بوجھ کر اس ورک فلو سے باہر رکھا گیا ہے۔

کیا rclone check --download کسی بھی کلاؤڈ میں تبدیلی کرتا ہے؟

نہیں۔ یہ فائل کا مواد پڑھ کر اس کا موازنہ کرتا ہے۔ اسکرپٹ ہر مرحلے کی کاپی کے بعد اسے استعمال کرتا ہے، تاکہ کسی راستے کا چیک پوائنٹ صرف اس وقت بنایا جائے جب منزل کی بائٹس اسٹیجنگ کی بائٹس سے مطابقت رکھتی ہوں۔

اگر منزل میں پہلے سے کوئی فائل موجود ہو تو کیا ہوتا ہے؟

کاپی میں --ignore-existing استعمال ہوتا ہے، جس کے بعد تمام بائٹس کی تصدیق کی جاتی ہے۔ یکساں آبجیکٹ تصدیق میں کامیاب ہو سکتا ہے؛ مختلف آبجیکٹ کی وجہ سے جانچ ناکام ہو جاتی ہے۔ اسکرپٹ کبھی بھی متصادم فائل کو اوور رائٹ نہیں کرتا۔

کیا اسکرپٹ ایک بیچ سے بڑی فائلیں سنبھال سکتا ہے؟

ہاں۔ حد سے بڑی ایک فائل اپنا الگ بیچ بن جاتی ہے۔ اسٹیجنگ فائل سسٹم میں اس فائل کے ساتھ کنفیگر کردہ مقامی محفوظ گنجائش کے لیے بھی جگہ ہونی چاہیے۔

کیا یہ اجازتیں، ورژنز یا کلاؤڈ کے مقامی اشتراکی ڈیٹا کو منتقل کرتا ہے؟

نہیں۔ یہ rclone کے ذریعے فائل کا مواد اور راستے کاپی کرتا ہے۔ رسائی کا کنٹرول، ورژنز، لیبلز، تبصرے، شارٹ کٹس، لنکس، برقرار رکھنے کے قواعد اور فراہم کنندہ کے مقامی طرزِ عمل کے لیے علیحدہ منصوبہ بندی اور تصدیق درکار ہے۔

اس رہنما مضمون کے لیے استعمال کیے گئے سرکاری وسائل

• Google Workspace لرننگ سینٹر: OneDrive سے Google Drive پر منتقل ہوں
• Google Drive مدد: اسٹوریج اور فائلوں کا طرزِ عمل
• Microsoft سپورٹ: OneDrive پر فائلیں اپ لوڈ اور محفوظ کریں
• rclone copy کمانڈ کا حوالہ
• rclone check اور تمام بائٹس کی تصدیق
• rclone lsf انوینٹری فارمیٹس
• rclone about کا کوٹا آؤٹ پٹ