Transferência na nuvem somente por cópia em Bash com rclone

Resposta curta

O FileArk é a opção gerenciada mais simples para migrações grandes ou sem supervisão: ele executa a transferência online, foi testado com cargas de trabalho de vários terabytes e verifica cada resultado antes da conclusão. Para operadores que querem controlar o fluxo de dados pelo shell, este wrapper em Bash com licença MIT copia lotes limitados por meio de uma área de preparação local, verifica os dois trechos byte a byte e nunca exclui arquivos da origem.

Por que criar um wrapper para o rclone em vez de reconstruir o cliente de cada provedor

O rclone oferece a um fluxo de trabalho em shell uma abstração madura de provedores, configuração de OAuth, paginação, comportamento de repetição, transferências retomáveis, controles de simultaneidade, comandos de inventário e comandos de verificação. Assim, o wrapper pode se concentrar nos invariantes da migração: comandos somente de cópia, área de preparação limitada, reservas de capacidade, listas determinísticas de arquivos e progresso persistente.

Isso não torna o trabalho automático. O operador continua responsável pela configuração dos remotos, pela segurança dos tokens, pela disponibilidade da rede, pela supervisão do processo, pelo disco local, pelos logs, pelos limites dos provedores, pela análise dos objetos com falha e pela aceitação do destino. O FileArk existe para usuários que querem que esse procedimento seja executado como um fluxo de trabalho online gerenciado, e não na própria estação de trabalho ou servidor.

O script nunca invoca explicitamente rclone move, sync, delete, purge ou rmdirs. Ele usa lsf e about para descoberta, copy em cada trecho e check --download para a verificação completa dos bytes. A única remoção é a de um arquivo verificado no diretório de preparação local.

Baixe a edição em Bash e a licença MIT

Execute a demonstração para operadores sem acesso à rede

É seguro executar a demonstração antes de instalar o rclone ou o jq, pois a análise dos argumentos termina antes das verificações de dependências. A saída nomeia as operações destrutivas proibidas, mostra ambas as reservas de capacidade e termina com a contagem de exclusões na origem.

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

Instale e configure as dependências para o operador

Instale uma versão atual do rclone seguindo as instruções oficiais e instale o jq através do gestor de pacotes do seu sistema operativo. É necessário o Bash 4 ou mais recente, porque o wrapper usa um tratamento rigoroso de erros e expressões condicionais modernas.

Execute rclone config e crie dois remotos com nomes distintos, por exemplo, onedrive: e gdrive:. Informe seu próprio ID e segredo de cliente do provedor quando a política ou os limites de uso exigirem aplicativos OAuth dedicados. O rclone armazena os tokens OAuth no arquivo de configuração; proteja esse arquivo com permissões restritivas e nunca o distribua junto com o script.

Confirme cada remoto com um comando de listagem somente para leitura e um comando de cota antes de executar o wrapper. Use caminhos como onedrive:Department/Archive quando apenas uma subárvore fizer parte do escopo.

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

Congele um inventário determinístico antes de transferir os bytes

O wrapper usa rclone lsf de forma recursiva, com um separador de tabulação explícito e o formato sp, produzindo o tamanho seguido do caminho. Ele valida se cada tamanho é numérico e cada caminho é relativo e, depois, exclui os caminhos que já constam no checkpoint verificado.

A edição em Bash rejeita nomes de arquivo que contenham tabulações, retornos de carro ou quebras de linha, pois as listas --files-from-raw delimitadas por quebras de linha não conseguem representá-los sem ambiguidade. Use a edição em Python ou um formato de inventário criado especificamente para isso quando esses nomes existirem.

Um checkpoint baseado em caminhos é intencionalmente simples e fácil de inspecionar. Ele pressupõe que os caminhos de origem permaneçam estáveis durante a execução. Se possível, suspenda as gravações na origem ou gere novamente e reconcilie o inventário quando forem esperadas alterações simultâneas.

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

\t' > "$inventory"

Interrompa antes que um lote consuma a reserva

Os bytes livres no armazenamento local são obtidos por meio de df no sistema de arquivos da área de preparação. Os bytes livres no destino são obtidos por meio de rclone about --json: o script usa free quando esse valor é fornecido; caso contrário, usa total menos used. Ele verifica o total de bytes pendentes antes de começar e verifica novamente as capacidades local e do destino antes de cada lote.

Alguns fornecedores ou tipos de conta não disponibilizam uma quota finita através do rclone. O wrapper indica essa limitação e prossegue sujeito às restrições impostas pelo fornecedor. Encare isso como um requisito de monitorização, não como prova de que existe espaço suficiente.

O limite do lote não é um máximo rígido para um único objeto. Um arquivo maior que o lote configurado pode formar seu próprio lote; portanto, o espaço local livre precisa comportar o maior arquivo mais a reserva. A verificação completa do destino lê os bytes no destino, mas, na edição com rclone, não mantém uma segunda cópia local.

Verifique ambos os lados do limite da área de preparação local

Cada lote percorre dois trechos independentes. Primeiro, o rclone copia os caminhos selecionados da origem para a área de preparação local usando --ignore-existing; em seguida, check --download lê os dois lados e compara o conteúdo real. Depois, o rclone copia esses caminhos da área de preparação para o destino e repete a mesma verificação completa dos bytes.

--ignore-existing torna as execuções interrompidas não destrutivas: um objeto existente não é sobrescrito. A verificação ainda precisa ser concluída com sucesso antes que o caminho possa ser registrado no checkpoint. Se o conteúdo existente no destino for diferente, rclone check falhará e o tratamento estrito de erros do Bash interromperá a execução.

Usar --download é mais lento e consome operações de leitura ou de saída do fornecedor, mas evita depender apenas da disponibilidade de um algoritmo de hash comum aos dois fornecedores. O comando não modifica nenhum dos lados.

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

Execute a transferência do OneDrive para o Google Drive com uma área de preparação limitada

O exemplo mantém 15 GiB do disco local intocados, preserva 10 GiB livres no Google Drive, limita um lote normal a 8 GiB ou 200 arquivos e usa quatro transferências simultâneas. O conteúdo de destino é gravado em uma nova pasta com data.

Use primeiro --dry-run. Esta opção faz o inventário da origem e a verificação preliminar da quota do destino sem transferir nem carregar dados. O wrapper apresenta o total de bytes pendentes, que deve ser comparado com o âmbito da migração antes do primeiro lote real.

./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.

Inverta a direção sem reutilizar o estado

O wrapper é independente do provedor porque o rclone gerencia os adaptadores remotos. Inverta os argumentos dos remotos para copiar do Google Drive para o OneDrive e forneça a essa execução uma nova pasta de destino, um novo caminho de preparação e um novo arquivo de checkpoint.

Os Docs, Sheets e Slides nativos do Google, bem como outros formatos virtuais, exigem a configuração da exportação no rclone e uma análise cuidadosa. Confirme as extensões exportadas e o comportamento da conversão com um conjunto de teste. Uma cópia através da shell não preserva o histórico de colaboração do Google, os atalhos, as permissões nem os metadados específicos da 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

Registre o checkpoint somente após verificar o destino

Depois que a verificação do destino é concluída com sucesso, o wrapper acrescenta cada caminho relativo a um checkpoint em texto simples. Em seguida, exclui esse arquivo da área de preparação local e remove os diretórios locais vazios. O remoto de origem permanece intocado.

Durante uma execução, o checkpoint permite apenas acréscimos e pode ser facilmente auditado com ferramentas padrão. Preserve-o junto com a linha de comando, a versão do rclone, a impressão digital da configuração, o inventário, os logs, os registros de data e hora e as notas de aceitação. Não o edite para ocultar uma falha, a menos que o arquivo no destino tenha sido verificado de forma independente.

Um ponto de controlo baseado apenas no caminho não consegue detetar um objeto de origem cujo conteúdo seja alterado sem que o caminho mude. Para conjuntos de dados mutáveis, suspenda as escritas, registe separadamente os IDs do fornecedor e os metadados de modificação ou use o ponto de controlo mais rigoroso por ID e tamanho da edição em Python. Para migrações regulamentadas ou colaborativas, use um fluxo de trabalho gerido com controlo explícito de alterações.

Trate toda saída diferente de zero como um lote não resolvido

• O modo estrito encerra a execução quando um comando ou pipeline falha, ou quando há uma variável não definida; o diretório temporário do inventário é removido automaticamente.
• O rclone repete transferências com falhas transitórias, mas erros persistentes de permissão, cota, rede, conflito ou integridade interrompem o lote.
• Os arquivos na área de preparação que não foram registrados no checkpoint permanecem disponíveis para inspeção, e uma nova execução idêntica usa --ignore-existing antes de verificar seus bytes.
• Um ficheiro diferente no destino nunca é substituído. Resolva o conflito ou escolha uma raiz de destino vazia.
• Não transforme uma cópia com falha em rclone sync ou move. Esses comandos têm outras regras de exclusão.
• Mantenha os logs e o checkpoint até concluir a aceitação manual do destino.

Proteja o anfitrião que se torna o plano de dados

O anfitrião da área de preparação contém temporariamente cópias legíveis dos dados de origem e tokens de atualização OAuth. Use encriptação integral do disco, permissões de ficheiros restritivas, uma conta dedicada do sistema operativo, dependências atualizadas, acesso controlado de administradores e uma política de cópias de segurança encriptadas que não retenha inesperadamente o conteúdo da área de preparação.

Evite segredos na linha de comando, pois as listas de processos e o histórico do shell podem expô-los. A configuração protegida do rclone pode ofuscar tokens armazenados, mas não substitui a segurança do host. Após a aceitação da migração, remova os dados dos tokens e os resíduos da área de preparação de acordo com sua política de retenção.

Monitore os logs de auditoria dos provedores, o tráfego de saída da rede, a integridade do disco, a disponibilidade de inodes, o status do processo e a saída do rclone. Deixar um terminal aberto não é supervisionar o processo; use um gerenciador de serviços ou multiplexador de terminal aprovado e armazene os logs de forma persistente.

Conclua a migração com evidências, não apenas com um comando bem-sucedido

• Arquive o inventário congelado, o comando exato, a soma de verificação do script, a versão do rclone, a impressão digital da configuração dos remotos e o checkpoint verificado.
• Compare as contagens de ficheiros e o volume conhecido em bytes por pasta, não apenas o total da unidade.
• Abra uma amostra baseada em risco de documentos grandes, pequenos, antigos, novos, com Unicode, profundamente aninhados, arquivados e convertidos.
• Teste o acesso ao destino usando contas de usuário representativas e recrie separadamente os compartilhamentos necessários.
• Analise pacotes ignorados, atalhos, links, documentos nativos, conflitos e avisos dos provedores.
• Mantenha um período de sobreposição com a origem e obtenha a aceitação explícita do proprietário antes de qualquer decisão posterior de retenção ou eliminação.

Perguntas frequentes

Porque é que o script Bash usa rclone copy em vez de sync?

A cópia não exclui objetos da origem nem remove objetos do destino que não existam na origem. A sincronização tem outras regras de reconciliação e exclusão, por isso foi intencionalmente deixada fora deste fluxo de trabalho.

O rclone check --download altera alguma das nuvens?

Não. Lê e compara o conteúdo dos ficheiros. O script usa esta operação depois de cada etapa de cópia, para que um caminho só seja registado no ponto de controlo quando os bytes no destino coincidirem com os bytes na área de preparação.

O que acontece quando o destino já contém um arquivo?

A cópia usa --ignore-existing e, em seguida, faz a verificação completa dos bytes. Um objeto idêntico pode passar; um objeto diferente faz a verificação falhar. O script nunca sobrescreve o arquivo conflitante.

O script consegue processar arquivos maiores que um lote?

Sim. Um ficheiro que exceda o tamanho definido torna-se um lote próprio. O sistema de ficheiros da área de preparação tem de dispor de espaço para esse ficheiro, além da reserva local configurada.

Isto migra permissões, versões ou dados de colaboração nativos da nuvem?

Não. Copia o conteúdo e os caminhos dos ficheiros através do rclone. O controlo de acesso, as versões, as etiquetas, os comentários, os atalhos, as ligações, as regras de retenção e o comportamento nativo do fornecedor exigem planeamento e verificação separados.

Recursos oficiais utilizados neste guia

• Centro de Aprendizagem do Google Workspace: mudar do OneDrive para o Google Drive
• Ajuda do Google Drive: armazenamento e comportamento dos ficheiros
• Suporte da Microsoft: carregar e guardar ficheiros no OneDrive
• Referência do comando rclone copy
• rclone check e verificação completa dos bytes
• Formatos de inventário do rclone lsf
• Saída de cota do rclone about