क्लाउड माइग्रेशन: फ़ाइल ट्रांसफर रणनीति गाइड

cloud migration file transfer रणनीति तीन निर्णयों पर टिकी है: transport path (public internet, Direct Connect, या physical appliance), cutover model (big-bang, phased, या parallel-run), और integrity checks जिन पर आप भरोसा करेंगे। 1 Gbps pipe पर 50 TB estate के लिए, wire speed पर लगभग 5 दिन के pure transfer time की अपेक्षा करें — यदि आप compress करते हैं तो कम, यदि line shared है तो अधिक। tooling plan करने से पहले sequence plan करें, और retries और reconciliation के लिए 20% headroom budget करें।

Wire छूने से पहले Dataset का आकार निर्धारित करना

AWS DataSync, Azure AzCopy, या Google Storage Transfer Service चुनने से पहले, inventory करें कि आपके पास वास्तव में क्या है। File shares पर du -sh चलाएं, row counts के लिए database catalogs query करें, और object-store manifests export करें। मैंने जिस mid-market company का audit किया उसने सोचा था कि उसके NAS पर 8 TB है; snapshots और hidden ~$ Office lock files गिनने के बाद वास्तविक संख्या 34 TB थी।

Inventory को तीन axes द्वारा classify करें: size, change rate, और regulatory weight। 1 MB से कम की फ़ाइलें per-object overhead के कारण प्रति byte धीमी चलती हैं — 200 million छोटी फ़ाइलों वाला bucket 10 TB video वाले से अधिक समय ले सकता है। Hot data (daily changes) को cold data से अलग rank करें (.pdf archives, 2017 invoices)। Cold data हफ्तों पहले ship हो सकता है; hot data को sync-until-cutover logic चाहिए।

Timeline से मेल खाता Transport चुनना

अच्छी fiber line के साथ 10 TB से कम के लिए, TLS 1.3 पर online transfer आमतौर पर जीतता है। 10 TB और 500 TB के बीच, corporate WAN को saturate करने से बचने के लिए bandwidth reserve करें या AWS Direct Connect / Azure ExpressRoute provision करें। 500 TB से ऊपर, physical seeding internet को हराती है: AWS Snowball Edge 80 TB रखता है, Snowmobile shipping container में exabytes move करता है, और Azure Data Box Heavy 1 PB store करता है।

Math ईमानदारी से करें। 1 Gbps (125 MB/s sustained, overhead के बाद realistically 80 MB/s) पर, 100 TB में लगभग 14 दिन का uninterrupted throughput लगता है। यदि आपकी operations window 48 घंटे है, wire viable नहीं है — disks ship करें। Egress factor करें: पुराने provider से $0.09/GB पर 100 TB बाहर निकालने में destination को touch करने से पहले ₹7.50 लाख खर्च होते हैं।

Integrity: भरोसा करें लेकिन Checksum करें

हर migration को end-to-end integrity verification चाहिए, केवल transport-layer TLS नहीं। Source पर SHA-256 या xxHash64 hashes generate करें, payload के साथ transmit करें, और destination पर फिर hash करें। AWS DataSync यह default पर करता है; --checksum के साथ rsync यह force करती है; rclone --check-first और crypt backends support करता है।

Compliance workloads के लिए, manifest रखें — path, byte-count, और hash की CSV — पूरी retention window के लिए। DPDP Act 2023 और Data Protection Board of India के दिशानिर्देश data fiduciaries को transfer के दौरान data integrity demonstrate करने की आवश्यकता करते हैं। HIPAA-covered entities को 45 CFR 164.312(c)(1) integrity controls के तहत हर object log करना चाहिए। DICOM study में एक misaligned byte radiologist के viewer को इसे खोलने से refuse कर सकता है।

Delta Sync के साथ Downtime कम करना

Big-bang cutovers नींद के दुश्मन हैं। इसके बजाय, हफ्तों पहले initial bulk copy करें, फिर cutover window तक nightly incremental deltas चलाएं। Rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer), और Google की gsutil rsync -d mtime या hash द्वारा changed फ़ाइलें detect करती हैं और केवल delta move करती हैं।

Databases को अपना plan चाहिए। 2 TB PostgreSQL instance के लिए, pg_basebackup plus WAL shipping उपयोग करें; MySQL के लिए, destination पर replica सेट करें और cutover के दौरान promote करें। rsync पर file-system deltas final sync को घंटों से मिनटों में drop कर सकती हैं, जो आमतौर पर शनिवार-रात maintenance window में fit होती है।

Bandwidth Shaping और Time-of-Day Transfers

Migrations जो WAN के हर bit को हog करती हैं बुरी तरह समाप्त होती हैं — नाश्ते से पहले help-desk tickets जमा हो जाते हैं। Aggressively throttle करें। AzCopy --cap-mbps accept करता है, rclone day/night rates के लिए --bwlimit 50M:100M support करता है, और DataSync प्रति घंटे bandwidth caps के साथ tasks schedule करता है। एक sensible policy: business hours के दौरान link का 30%, रात में 90%, weekends पर 100%।

Firewall पर traffic भी segment करें। Migration flows को DSCP value के साथ tag करें ताकि QoS policies Zoom calls को starve न करें। यदि आप branch offices पर MPLS उपयोग कर रहे हैं, SD-WAN breakout consider करें ताकि migration traffic headquarters के माध्यम से trombone करने के बजाय locally exit करे।

Transit में Sensitive Data Handle करना

PII, PHI, या cardholder data शामिल किसी भी migration को relevant standard पूरा करने वाला encryption चाहिए। TLS 1.3 floor है; staging के दौरान rest पर फ़ाइलों के लिए, upload से पहले AES-256-GCM से wrap करें। PCI DSS 4.0 Requirement 4.2.1 public networks पर cardholder data के लिए strong cryptography अनिवार्य करता है। भारतीय संदर्भ में, DPDP Act 2023 की धारा 8(7) data fiduciaries को appropriate technical measures के माध्यम से personal data की सुरक्षा सुनिश्चित करने की आवश्यकता करती है।

Migration के दौरान छोटे batches के ad-hoc transfers के लिए (सोचें: एक consultant Salesforce table export कर रहा है या DBA credentials vault move कर रहा है), end-to-end encrypted tools keys को transport provider की reach से बाहर रखते हैं। HexaTransfer migration के दौरान one-off फ़ाइलों के लिए यह साफ-साफ handle करता है — encryption browser में होती है किसी भी चीज़ के server को touch करने से पहले।

Cutover से पहले Cutover का परीक्षण

Migration को subset पर dress-rehearse करें। एक department चुनें — मान लीजिए Marketing की shared drive का 300 GB — और पूरा pipeline चलाएं: source inventory, transfer, checksum verify, permission mapping, और application failover। प्रत्येक step का समय लें और document करें कि क्या टूटा।

सामान्य आश्चर्य: NTFS ACLs जो S3 bucket policies पर cleanly map नहीं होते, symlinks जिन्हें rclone files मानती है, application configs में embedded SMB share paths, और Windows और Linux destinations के बीच case-sensitivity differences। उन्हें staging में ठीक करें, go-live रात को सुबह 2 बजे नहीं। एक week लेने वाला rehearsal एक महीने लेने वाले rollback को बचाता है।

Migration के बाद Reconciliation

Reconciliation के बाद ही सफलता declare करें। Source और destination object counts, total bytes, और एक random 1% hash sample compare करें। Application metrics query करें — यदि document-management system ने 4.2 million फ़ाइलें report कीं और destination 4.19 million दिखाता है, तो source बंद करने से पहले missing 10,000 खोजें।

Cutover के बाद कम से कम 30 दिनों के लिए source को read-only रखें। Users अनिवार्य रूप से एक ऐसी फ़ाइल खोजेंगे जिनकी उन्हें ज़रूरत है जो migrate नहीं हुई क्योंकि वह inventoried share के बजाय ~/Desktop/old_stuff/ में थी। इसका budget करें, इससे हैरान न हों, और rollback runbook लिखें इससे पहले कि आपको इसकी ज़रूरत हो।

hexatransfer.com पर आज़माएं — मुफ़्त, कोई अकाउंट नहीं, अधिकतम 10 GB।