Python · Google Drive ↔ OneDrive · Guia de engenharia de código aberto

Crie uma transferência segura entre o Google Drive e o OneDrive em Python

Este guia transforma uma cópia entre clouds, cuja dificuldade pode ser enganadora, num fluxo explícito: enumerar, fazer verificações preliminares, colocar na área temporária, calcular o hash, enviar, voltar a transferir, comparar, criar um ponto de controlo e só então libertar espaço no disco local.

Atualizado ; 22 min de leitura.

Resposta curta

Numa migração gerida, o FileArk automatiza este fluxo de trabalho sem transformar o seu computador no plano de dados. Foi testado com cargas de trabalho de migração de vários terabytes e verifica a receção dos dados da origem, a aceitação do carregamento pelo fornecedor e o objeto no destino antes de comunicar o sucesso. Se precisar de operar o pipeline por conta própria, o programa em Python com licença MIT abaixo realiza uma cópia cautelosa através do seu computador e nunca elimina ficheiros da origem.

Escolha o modelo operacional antes de escolher o código

Um serviço de migração direta entre clouds é a opção prática quando a biblioteca é grande, a ligação tem de funcionar sem supervisão ou os dados não devem passar por um portátil. O FileArk mantém a transferência online, monitoriza as respostas dos fornecedores, repete as tentativas após falhas recuperáveis e apresenta todo o progresso num único local. O respetivo processo de validação realiza três verificações independentes antes de considerar um ficheiro concluído.

Um script local é útil quando precisa de controlo total sobre as aplicações OAuth, os discos de armazenamento temporário, os registos ou a política de pastas de destino. A contrapartida é a responsabilidade operacional: o seu computador tem de permanecer ligado, a respetiva ligação de rede torna-se o estrangulamento, as credenciais OAuth têm de ser protegidas e deve permanecer disponível espaço temporário suficiente em disco para o lote ativo e a cópia de verificação.

O programa aqui disponibilizado é intencionalmente conservador. Copia a partir da raiz de um drive pessoal para uma nova pasta de destino. Não disponibiliza um método de eliminação, não substitui ficheiros em caso de conflito, guarda um ponto de controlo persistente após a verificação e para quando a capacidade local ou do destino fica abaixo da reserva configurada.

O pipeline de transferência e os limites das respetivas falhas

  1. Inventariar a árvore da origem

    O adaptador da origem percorre as pastas recursivamente, segue a paginação do fornecedor, regista IDs, caminhos, tipos e tamanhos comunicados, e associa os ficheiros nativos da Google suportados a formatos de exportação portáteis.

  2. Verificar previamente a capacidade local e do destino

    O motor compara os bytes pendentes mais uma reserva configurável com a quota do destino. Também verifica o sistema de ficheiros da área temporária antes de cada lote e de cada transferência individual.

  3. Colocar um lote limitado na área temporária

    Os ficheiros são processados em lotes limitados tanto pelo total de bytes como pelo número de ficheiros. Apenas o lote atual utiliza o disco local, pelo que uma biblioteca grande não exige um disco com a mesma capacidade.

  4. Calcular o hash e enviar

    Após a transferência, o script calcula localmente o SHA-256, verifica qualquer tamanho conhecido na origem, cria as pastas de destino e envia os ficheiros em segmentos retomáveis compatíveis com o fornecedor.

  5. Verificar e criar um ponto de controlo

    O modo predefinido volta a transferir o novo objeto do destino e compara o SHA-256. Só depois de confirmar a correspondência é que o ficheiro é registado no ponto de controlo JSON e removido da área temporária local.

Transfira a edição completa em Python com licença MIT

A transferência consiste num único ponto de entrada Python legível. Os SDKs dos fornecedores só são importados para uma transferência real, pelo que os comandos de demonstração e ajuda são executados antes da instalação das dependências ou credenciais. Um ficheiro de requisitos separado fixa as versões mínimas dos pacotes suportados, e a licença é fornecida junto do código-fonte.

Leia o código antes de o utilizar, teste-o com uma pasta de destino pequena e mantenha a verificação predefinida por nova transferência para dados valiosos. Nenhum script genérico consegue reproduzir todas as permissões de partilha, atalhos, etiquetas de retenção, regras de drives partilhados ou políticas de inquilino.

Transferir o programa Python de transferência
Implementação direta da API do Google Drive e do Microsoft Graph com processamento em lotes, pontos de controlo, novas tentativas, reservas de quota e verificação SHA-256 no destino.
fileark-cloud-transfer.py · Python 3.10+ · licença MIT

Transferir os requisitos do Python
Pequena lista de dependências para o OAuth e o Drive da Google, a autenticação da Microsoft, os pedidos ao Graph e o suporte para novas tentativas.
requirements-fileark-cloud-transfer.txt · requisitos do pip · texto simples

Transferir a licença MIT
Aviso de autorização que abrange ambos os scripts de transferência manual da FileArk.
LICENSE-fileark-cloud-transfer.txt · MIT · texto simples

Consulte o processo de segurança antes de conceder acesso à cloud

Terminal a executar o script Python da FileArk para transferências entre clouds no modo de demonstração sem rede
A demonstração integrada percorre o fluxo apresentado ao operador sem credenciais nem chamadas de rede. Uma execução real apresenta o mesmo estado de capacidade, lotes, verificação, ponto de controlo e eliminação da origem.

Execute primeiro a demonstração. Não efetua chamadas de rede nem grava dados na cloud. A última linha é deliberadamente inequívoca: foram eliminados zero ficheiros da origem. O motor real emite a mesma sequência através de registos estruturados e termina com um código diferente de zero ao encontrar o primeiro ficheiro não verificado.

Teste rápido sem rede
chmod +x fileark-cloud-transfer.py
python3 fileark-cloud-transfer.py --demo
python3 fileark-cloud-transfer.py --help

Criar clientes OAuth sem incorporar segredos

Para o Google Drive, crie um cliente OAuth para computador num projeto do Google Cloud, ative a API Drive, configure o ecrã de consentimento e transfira o JSON do cliente. Indique o respetivo caminho com --google-client-secret ou defina GOOGLE_OAUTH_CLIENT_SECRET_FILE. O script solicita acesso ao Drive porque precisa de listar e transferir ficheiros, criar pastas, enviar ficheiros e verificá-los.

Para o OneDrive, registe uma aplicação cliente pública no Microsoft Entra ID, ative o fluxo de código de dispositivo, adicione a permissão delegada Files.ReadWrite e forneça o ID de cliente da aplicação. Escolha `common` para contas pessoais e organizacionais, `organizations` para contas profissionais ou um ID de inquilino específico quando a política assim o exigir.

Os tokens são armazenados em cache em ficheiros locais para que uma migração interrompida possa ser retomada sem um novo início de sessão. Trate o JSON do cliente e as caches de tokens como segredos: exclua-os do controlo de versões, restrinja as permissões do sistema de ficheiros, nunca os carregue em pedidos de suporte e remova-os quando a migração for aceite.

Instalar as dependências num ambiente isolado
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements-fileark-cloud-transfer.txt

Execute a transferência do Google Drive para o OneDrive — ou no sentido inverso

Todos os valores específicos da identidade pertencem ao operador. O programa não inclui qualquer ID de cliente, segredo, inquilino, token, conta remota ou credencial do destino. O primeiro comando inicia sessão na Google através de um navegador e na Microsoft com um código de dispositivo, copiando depois os dados para uma nova pasta do OneDrive.

Inverta a origem e o destino para transferir do OneDrive para o Google Drive. Utilize um ficheiro de estado e uma raiz de destino diferentes para cada migração independente. O ponto de controlo associa o fornecedor de origem, o fornecedor de destino e a raiz, e recusa retomar a operação se a configuração não corresponder.

Do Google Drive para o OneDrive com lotes de 8 GiB
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
Sentido inverso: do OneDrive para o Google Drive
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

Por que motivo a capacidade é verificada mais do que uma vez

Uma única verificação prévia pode ficar desatualizada durante uma transferência longa. Alguém pode carregar outros ficheiros para o destino, um documento Google exportado pode ser maior do que os respetivos metadados de origem sugerem e aplicações não relacionadas podem ocupar espaço no disco local. Por isso, o motor verifica a capacidade total do destino antes de começar, a capacidade do destino em cada lote e novamente após cada transferência para o armazenamento local, bem como o disco local antes de cada cópia temporária ou de verificação.

Os valores de reserva constituem uma margem operacional, não estimativas do tamanho da transferência. Defina-os com valores suficientemente elevados para acomodar atualizações do sistema operativo, atrasos na contabilização do fornecedor e outros utilizadores da mesma quota de cloud. Quando um fornecedor não indica uma quota restante finita, o script apresenta um aviso e depende da aplicação dos limites pelo fornecedor; isto é menos fiável do que uma verificação prévia com valores conhecidos e exige monitorização ativa.

A invariante de quota com bloqueio em caso de falha
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."
        )

Limitar a área temporária por bytes e número de ficheiros

Um limite de bytes controla a utilização do disco; um limite de número de ficheiros controla a sobrecarga da API e do sistema de ficheiros quando a origem contém centenas de milhares de objetos pequenos. Um ficheiro maior do que o limite do lote é permitido como lote de um único ficheiro, pelo que a reserva deve ser dimensionada para o maior objeto individual.

O bloco predefinido é de 10 MiB. Este valor é um múltiplo comum da granularidade de 256 KiB dos carregamentos retomáveis do Google Drive e do requisito de fragmentos sequenciais de 320 KiB do Microsoft Graph. O validador da linha de comandos rejeita tamanhos de bloco incompatíveis antes da autenticação.

Planeador de lotes com dois limites
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

Tratar os documentos nativos da Google como conversões

Os projetos do Google Docs, Sheets, Slides, Drawings e Apps Script não são fluxos de bytes comuns que possam ser transferidos. O adaptador da Google exporta-os, respetivamente, para DOCX, XLSX, PPTX, PNG e JSON, adicionando uma extensão de nome de ficheiro portátil. As pastas são percorridas, mas não são enviadas como objetos vazios, exceto se contiverem um ficheiro.

A conversão pode alterar tipos de letra, fórmulas, comentários, objetos incorporados, o esquema das páginas e o histórico de colaboração. Os endpoints de exportação da Google também impõem restrições de formato e tamanho. O script ignora tipos nativos não suportados e apresenta um aviso, em vez de inventar uma representação. Analise manualmente uma seleção representativa dos ficheiros convertidos.

Atalhos, drives partilhados, ficheiros partilhados consigo mas que não se encontram em O meu disco, pacotes do OneNote, metadados de retenção da organização, histórico de versões e ACLs de partilha estão fora do âmbito desta edição. Devido a estas limitações, uma cópia de ficheiros não deve ser descrita como uma migração completa do inquilino.

Utilize a verificação completa por nova transferência a partir do destino para confirmar os bytes exatos

O sucesso do carregamento para o fornecedor é necessário, mas não suficiente. Após o carregamento, o script começa por comparar o tamanho indicado nos metadados do destino com o ficheiro na área temporária. No modo predefinido de nova transferência, transfere depois o objeto do destino para um ficheiro temporário adjacente, calcula o SHA-256 e compara esse resumo com o resumo do ficheiro de origem na área temporária.

Só uma correspondência de tamanho e de resumo criptográfico gera uma entrada no ponto de controlo. O ponto de controlo regista o ID da origem, o tamanho comunicado pela origem, o ID do destino, o caminho de destino, os bytes reais, ambos os resumos e a hora de conclusão em UTC. Se um caminho da origem registado no ponto de controlo passar posteriormente a apontar para um ID ou tamanho diferente, o script para em vez de ignorar silenciosamente os dados alterados.

Voltar a transferir duplica o tráfego de leitura no destino e exige temporariamente espaço tanto para o ficheiro na área temporária como para a cópia de verificação. Selecione o modo de metadados apenas quando esse custo for compreendido e existir um processo independente de verificação de conteúdo.

Verificação dos bytes no destino
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,
}

Retomar sem tratar a incerteza como sucesso

O programa grava o estado de forma atómica através de um ficheiro temporário e da respetiva mudança de nome. Um item verificado só é removido da área temporária local após essa gravação persistente. Voltar a executar o mesmo comando ignora os itens registados no ponto de controlo e continua com os caminhos pendentes.

Pode ocorrer uma falha após o fornecedor aceitar um carregamento, mas antes de o ponto de controlo ser escrito. Como o comportamento em caso de conflito está definido como `fail`, a execução seguinte para nesse caminho de destino já existente, em vez de o substituir ou comunicar falsamente o sucesso. Inspecione e compare o objeto; depois, adicione cuidadosamente uma entrada de recuperação verificada ou reinicie a transferência numa nova raiz de destino.

Quando ocorrem a expiração do OAuth, a limitação da taxa, erros transitórios do servidor ou a interrupção de blocos, são efetuadas novas tentativas dentro de limites definidos. Falhas de autenticação ou de permissões persistentes interrompem o programa. Preserve os registos, o ponto de controlo e o conteúdo da área temporária até compreender a falha.

Realizar um verdadeiro teste de aceitação

  • Comece com uma pasta pequena que contenha ficheiros vazios, ficheiros grandes, caminhos profundos, nomes Unicode e documentos nativos da Google.
  • Execute primeiro --dry-run e compare o total de bytes do inventário com a interface do fornecedor.
  • Monitorize separadamente o espaço local livre e a quota do destino durante o primeiro lote em produção.
  • Mantenha ativa a verificação por nova transferência e arquive o ponto de controlo juntamente com os registos da migração.
  • Abra no destino uma seleção representativa de PDFs, ficheiros do Office, imagens, vídeos, arquivos e documentos nativos convertidos.
  • Compare as quantidades esperadas de pastas e ficheiros, investigue cada item ignorado ou com falha e teste o acesso a partir de um segundo utilizador.
  • Mantenha a origem inalterada durante um período de sobreposição definido. Este script nunca a elimina.

Perguntas frequentes

O script Python elimina alguma vez ficheiros da origem?

Não. A eliminação da origem não está implementada. O motor transfere os dados da origem e grava-os numa raiz de destino separada; uma verificação bem-sucedida apenas remove a cópia temporária da área local.

Consegue transferir em ambas as direções?

Sim. Defina o Google Drive ou o OneDrive como origem e o outro fornecedor como destino. Utilize um ponto de controlo e uma raiz de destino exclusivos para cada migração.

Preserva as permissões de partilha e o histórico dos ficheiros?

Não. Esta edição copia o conteúdo atual dos ficheiros e os caminhos das pastas. ACLs de partilha, ligações públicas, versões, comentários, etiquetas, políticas de retenção e metadados específicos da organização exigem uma migração e validação separadas.

Por que motivo voltar a transferir ficheiros que acabaram de ser enviados?

A aceitação do carregamento e o tamanho indicado nos metadados não provam que é possível voltar a ler os bytes exatos no destino. O modo de nova transferência calcula o SHA-256 do conteúdo no destino e só cria um ponto de controlo quando existe uma correspondência exata.

Esta é uma ferramenta oficial da Google ou da Microsoft?

Não. É uma implementação de referência independente da FileArk, disponibilizada ao abrigo da licença MIT. Reveja-a, teste-a com dados não críticos e cumpra as políticas do seu fornecedor e da sua organização.

Recursos oficiais utilizados neste guia

Ler o guia