Skapa en säker överföring mellan Google Drive och OneDrive i Python

Kort svar

För en hanterad migrering automatiserar FileArk det här arbetsflödet utan att använda din dator som dataplan. Tjänsten har testats med migreringslaster på flera terabyte och kontrollerar mottagandet från källan, leverantörens godkännande av uppladdningen och målobjektet innan den rapporterar att överföringen lyckades. Om du behöver hantera flödet själv utför det MIT-licensierade Python-programmet nedan en försiktig kopiering via din dator och raderar aldrig källfiler.

Välj driftmodell innan du väljer kod

En direkt molnmigreringstjänst är det praktiska valet när biblioteket är stort, anslutningen måste kunna köras utan tillsyn eller data inte bör gå via en bärbar dator. FileArk håller överföringen online, övervakar leverantörernas svar, försöker igen efter fel som går att återhämta och ger dig en samlad förloppsvy. Valideringsflödet utför tre oberoende kontroller innan en fil betraktas som slutförd.

Ett lokalt skript är användbart när du behöver full kontroll över OAuth-applikationer, mellanlagringsdiskar, loggar eller principer för målmappar. Nackdelen är det operativa ansvaret: datorn måste förbli ansluten, nätverksanslutningen blir flaskhalsen, OAuth-autentiseringsuppgifterna måste skyddas och det måste finnas tillräckligt med tillfälligt diskutrymme för den aktiva batchen och verifieringskopian.

Programmet som publiceras här är avsiktligt försiktigt utformat. Det kopierar från roten på en personlig enhet till en ny målmapp. Det exponerar ingen raderingsmetod, skriver inte över vid konflikter, sparar en beständig kontrollpunkt efter verifieringen och stoppas när antingen den lokala kapaciteten eller målkapaciteten understiger den reserv du har konfigurerat.

Överföringsflödet och dess felgränser

1. Inventera källans mappstruktur

   Källadaptern går rekursivt igenom mappar, följer leverantörens paginering, registrerar ID:n, sökvägar, typer och rapporterade storlekar samt mappar Google-format som stöds till portabla exportformat.

2. Förkontrollera kapaciteten på målet och lokalt

   Motorn jämför antalet väntande byte plus en konfigurerbar reserv med målkvoten. Den kontrollerar även mellanlagringsfilsystemet före varje batch och varje enskild nedladdning.

3. Mellanlagra en avgränsad batch

   Filer bearbetas i batcher som begränsas av både det totala antalet byte och antalet filer. Endast den aktuella batchen använder den lokala disken, så ett stort bibliotek kräver inte en lika stor enhet.

4. Beräkna kontrollsumma och ladda upp

   Efter nedladdningen beräknar skriptet lokal SHA-256, kontrollerar eventuell känd källstorlek, skapar målmappar och laddar upp i återupptagningsbara delar som är kompatibla med leverantören.

5. Verifiera och skapa en kontrollpunkt

   I standardläget laddas det nya målobjektet ned igen och SHA-256 jämförs. Endast en matchande fil skrivs till JSON-kontrollpunkten och tas bort från den lokala mellanlagringen.

Ladda ned den fullständiga MIT-licensierade Python-versionen

Nedladdningen består av en enda lättläst startpunkt i Python. Leverantörernas SDK:er importeras endast vid en verklig överföring, så demonstrations- och hjälpkommandona kan köras innan beroenden eller autentiseringsuppgifter har installerats. En separat kravfil anger de lägsta paketversioner som stöds, och licensen medföljer bredvid källkoden.

Läs koden innan du använder den, testa med en liten målmapp och behåll standardinställningen för verifiering genom ny nedladdning för värdefulla data. Inget generellt skript kan återskapa alla delningsbehörigheter, genvägar, bevarandeetiketter, regler för delade enheter eller klientorganisationens principer.

Granska säkerhetsflödet innan du beviljar åtkomst till molnet

Kör demonstrationen först. Den gör inga nätverksanrop och skriver inga data till molnet. Den sista raden är avsiktligt otvetydig: noll källfiler raderades. Den verkliga motorn rapporterar samma sekvens via strukturerade loggar och avslutas med en annan kod än noll vid den första overifierade filen.

chmod +x fileark-cloud-transfer.py
python3 fileark-cloud-transfer.py --demo
python3 fileark-cloud-transfer.py --help

Skapa OAuth-klienter utan att bädda in hemligheter

För Google Drive skapar du en OAuth-klient för datorer i ett Google Cloud-projekt, aktiverar Drive API, konfigurerar samtyckesskärmen och laddar ned klientens JSON-fil. Ange sökvägen med --google-client-secret eller ställ in GOOGLE_OAUTH_CLIENT_SECRET_FILE. Skriptet begär åtkomst till Drive eftersom det måste kunna lista och ladda ned filer samt skapa mappar, ladda upp och verifiera filer.

För OneDrive registrerar du en offentlig klientapplikation i Microsoft Entra ID, aktiverar enhetskodflödet, lägger till den delegerade behörigheten Files.ReadWrite och anger applikationens klient-ID. Välj common för privata konton och organisationskonton, organizations för arbetskonton eller ett specifikt klientorganisations-ID när principerna kräver det.

Token cachelagras i lokala filer så att en avbruten migrering kan återupptas utan en ny inloggning. Behandla klientens JSON-fil och token-cachefiler som hemligheter: undanta dem från versionshantering, begränsa filsystemets behörigheter, ladda aldrig upp dem i supportärenden och ta bort dem när migreringen har godkänts.

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements-fileark-cloud-transfer.txt

Kör från Google Drive till OneDrive – eller åt andra hållet

Alla identitetsspecifika värden tillhör operatören. Programmet levereras utan klient-ID, hemlighet, klientorganisation, token, fjärrkonto eller autentiseringsuppgifter för målet. Det första kommandot loggar in på Google i en webbläsare och på Microsoft med en enhetskod och kopierar sedan till en ny mapp i OneDrive.

Byt plats på källa och mål för att köra från OneDrive till Google Drive. Använd en annan tillståndsfil och målrot för varje fristående migrering. Kontrollpunkten binder samman källleverantör, målleverantör och rot och vägrar att återuppta med en konfiguration som inte stämmer överens.

export MICROSOFT_CLIENT_ID="your-public-client-id"
python fileark-cloud-transfer.py \
  --source google \
  --destination onedrive \
  --google-client-secret ./client_secret.json \
  --microsoft-tenant common \
  --destination-root "FileArk Manual Transfer 2026-07-25" \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --verification redownload

python fileark-cloud-transfer.py \
  --source onedrive \
  --destination google \
  --microsoft-client-id "$MICROSOFT_CLIENT_ID" \
  --google-client-secret ./client_secret.json \
  --destination-root "OneDrive archive 2026-07-25" \
  --state-file ./onedrive-to-google-state.json \
  --verification redownload

Varför kapaciteten kontrolleras mer än en gång

En enskild förkontroll kan bli inaktuell under en lång överföring. Någon kan ladda upp andra filer till målet, ett exporterat Google-dokument kan vara större än vad källans metadata antyder och andra program kan förbruka lokalt diskutrymme. Motorn kontrollerar därför målets sammanlagda kapacitet före start, målets kapacitet vid varje batch, målets kapacitet igen efter varje lokal nedladdning samt det lokala diskutrymmet före varje mellanlagrings- eller verifieringskopia.

Reservvärdena är operativa marginaler, inte uppskattningar av överföringens storlek. Håll dem tillräckligt stora för uppdateringar av operativsystemet, fördröjningar i leverantörens kvotredovisning och andra användare av samma molnkvot. När en leverantör inte visar en ändlig återstående kvot varnar skriptet och förlitar sig på leverantörens begränsningar. Det är svagare än en förkontroll med ett känt värde och kräver aktiv övervakning.

def ensure_destination_capacity(quota, required, reserve):
    if quota.remaining is None:
        LOG.warning("Destination did not report a finite quota")
        return
    needed = required + reserve
    if quota.remaining < needed:
        raise RuntimeError(
            f"Destination is too small: {human_bytes(quota.remaining)} free, "
            f"{human_bytes(needed)} required including reserve."
        )

Begränsa mellanlagringen efter antal byte och filer

En bytegräns begränsar användningen av diskutrymme, medan en gräns för antalet filer begränsar belastningen på API och filsystem när källan innehåller hundratusentals små objekt. En fil som är större än batchgränsen tillåts som en batch med en enda fil, så reserven måste dimensioneras för det största enskilda objektet.

Standardstorleken för ett segment är 10 MiB. Det är en gemensam multipel av Google Drives granularitet på 256 KiB för återupptagningsbara uppladdningar och Microsoft Graphs krav på sekventiella fragment på 320 KiB. Kommandoradsvalidatorn avvisar inkompatibla segmentstorlekar före autentiseringen.

def batches(files, max_bytes, max_files):
    batch, batch_size = [], 0
    for item in files:
        planned_size = max(item.size, 1)
        if batch and (
            len(batch) >= max_files
            or batch_size + planned_size > max_bytes
        ):
            yield batch
            batch, batch_size = [], 0
        batch.append(item)
        batch_size += planned_size
    if batch:
        yield batch

Hantera dokument i Googles egna format genom konvertering

Google Dokument, Kalkylark, Presentationer, Teckningar och Apps Script-projekt är inte vanliga nedladdningsbara byteflöden. Google-adaptern exporterar dem till DOCX, XLSX, PPTX, PNG respektive JSON och lägger till ett portabelt filnamnstillägg. Mappar genomsöks men laddas inte upp som tomma objekt om de inte innehåller en fil.

Konvertering kan ändra typsnitt, formler, kommentarer, inbäddade objekt, sidlayout och samarbetshistorik. Googles exportslutpunkter har också begränsningar för format och storlek. Skriptet hoppar över inbyggda format som inte stöds och visar en varning i stället för att skapa en godtycklig representation. Granska representativa konverterade filer manuellt.

Genvägar, delade enheter, filer som har delats med dig men inte finns i Min enhet, OneNote-paket, organisationens metadata för bevarande, versionshistorik och ACL:er för delning omfattas inte av den här utgåvan. Dessa begränsningar är anledningen till att en filkopiering inte bör beskrivas som en fullständig migrering av en klientorganisation.

Verifiera exakta byte genom fullständig ny nedladdning från målet

Att leverantören godkänner uppladdningen är nödvändigt men inte tillräckligt. Efter uppladdningen jämför skriptet först filstorleken i målets metadata med den mellanlagrade filen. I standardläget för ny nedladdning hämtas sedan målobjektet till en tillfällig fil i samma katalog, SHA-256 beräknas och kontrollsumman jämförs med den mellanlagrade källfilens kontrollsumma.

En post skapas i kontrollpunkten endast om både storleken och kontrollsumman stämmer överens. Kontrollpunkten registrerar käll-ID, storleken som källan rapporterar, mål-ID, målsökväg, faktiskt antal byte, båda kontrollsummorna och slutförandetiden i UTC. Om en källsökväg med kontrollpunkt senare pekar på ett annat ID eller en annan storlek stoppas skriptet i stället för att utan varning hoppa över ändrade data.

En ny nedladdning fördubblar lästrafiken på målsidan och kräver tillfälligt utrymme för både den mellanlagrade filen och verifieringskopian. Välj metadataläget endast om du förstår kostnaden och det finns en oberoende process för innehållsverifiering.

destination.redownload(uploaded, verification_copy)
verification_hash = sha256_file(verification_copy)
if verification_hash != local_hash:
    raise RuntimeError(
        f"SHA-256 mismatch after destination re-download: {relative!r}."
    )

state["completed"][relative] = {
    "source_id": item.id,
    "destination_id": uploaded.id,
    "bytes": actual_size,
    "sha256": local_hash,
    "destination_sha256": verification_hash,
}

Återuppta utan att betrakta osäkerhet som framgång

Programmet skriver tillståndet atomärt via en temporär fil som sedan byter namn. Ett verifierat objekt tas bort från den lokala mellanlagringen först efter denna beständiga skrivning. Om samma kommando körs igen hoppas objekt med kontrollpunkter över och bearbetningen fortsätter med väntande sökvägar.

En krasch kan inträffa efter att leverantören har godkänt en uppladdning men innan kontrollpunkten har skrivits. Eftersom konfliktbeteendet är ”fail” stoppas nästa körning vid den befintliga målsökvägen i stället för att skriva över eller felaktigt uppge att överföringen lyckades. Inspektera objektet och jämför det. Lägg sedan antingen försiktigt till en verifierad återställningspost eller starta om med en ny rotkatalog på målet.

Försök görs på nytt inom fastställda gränser vid utgången OAuth-session, hastighetsbegränsning, tillfälliga serverfel och avbrutna segment. Autentiseringsfel eller bestående behörighetsfel stoppar programmet. Behåll loggar, kontrollpunkt och mellanlagrat innehåll tills du förstår felet.

Genomför ett verkligt acceptanstest

• Börja med en liten mapp som innehåller tomma filer, stora filer, djupa sökvägar, Unicode-namn och dokument i Googles egna format.
• Kör först --dry-run och jämför inventeringens totala antal byte med uppgifterna i leverantörens gränssnitt.
• Övervaka lokalt ledigt utrymme och målkvoten oberoende av varandra under den första produktionsbatchen.
• Låt verifiering genom ny nedladdning vara aktiverad och arkivera kontrollpunkten tillsammans med dina migreringsprotokoll.
• Öppna representativa PDF-filer, Office-filer, bilder, videor, arkiv och konverterade inbyggda dokument på målet.
• Jämför förväntat antal mappar och filer, undersök varje objekt som hoppats över eller misslyckats och testa åtkomsten med en annan användare.
• Låt källan vara oförändrad under en fastställd överlappningsperiod. Det här skriptet raderar den aldrig.

Vanliga frågor

Raderar Python-skriptet någonsin källfiler?

Nej. Radering av källan är inte implementerad. Motorn laddar ned från källan och skriver till en separat rotkatalog på målet. En lyckad verifiering tar endast bort den tillfälliga lokala mellanlagringskopian.

Kan det överföra i båda riktningarna?

Ja. Ange Google Drive eller OneDrive som källa och den andra leverantören som mål. Använd en unik kontrollpunkt och målrot för varje migrering.

Bevarar det delningsbehörigheter och filhistorik?

Nej. Den här utgåvan kopierar filernas aktuella innehåll och mappsökvägar. ACL:er för delning, offentliga länkar, versioner, kommentarer, etiketter, bevarandeprinciper och organisationsspecifika metadata kräver separat migrering och validering.

Varför ladda ned filer på nytt direkt efter uppladdningen?

Att uppladdningen godkänns och storleken i metadata stämmer bevisar inte att exakt samma byte kan läsas tillbaka från målet. Läget för ny nedladdning beräknar SHA-256 för innehållet på målet och skapar en kontrollpunkt endast vid en exakt matchning.

Är det här ett officiellt verktyg från Google eller Microsoft?

Nej. Det är en oberoende referensimplementation från FileArk som publiceras under MIT-licensen. Granska den, testa den med icke-kritiska data och följ leverantörens och organisationens principer.

Officiella resurser som använts för den här guiden

• Google Workspace utbildningscenter: byt från OneDrive till Google Drive
• Hjälp för Google Drive: lagring och filhantering
• Microsoft Support: ladda upp och spara filer på OneDrive
• Google Drive API: ladda ned och exportera filer
• Google Drive API: återupptagningsbara uppladdningar
• Google Drive API: fält för lagringskvot
• Microsoft Graph: lista underordnade objekt på en enhet
• Microsoft Graph: skapa en återupptagningsbar uppladdningssession
• Microsoft Graph: OneDrive-resurs för kvot