Como migrar do ownCloud 10 Classic para o ownCloud Infinite Scale

Cenário ilustrativo: Imagine uma empresa de design fictícia com 32 funcionários, a Cedar Studio, que utiliza o ownCloud Classic 10 com um diretório LDAP, áreas de arquivos pessoais, compartilhamentos de grupo, links públicos e um ponto de montagem para armazenamento externo de projetos. A empresa deseja migrar para o ownCloud Infinite Scale (oCIS) sem presumir que a instalação de um novo servidor transferirá seus dados ou permissões. Este exemplo é hipotético; não se trata de um relato de uma migração concluída.

O caminho recomendado e documentado pelo ownCloud é uma migração guiada usando o migrate-to-ocisaplicativo no servidor Classic e occcomandos. Trata-se de uma transferência em etapas para um destino oCIS separado e limpo, e não uma atualização direta do banco de dados ou diretório de dados do Classic. O manual de migração afirma que a origem permanece operacional durante a maior parte do processo, mas não descreve a sincronização contínua nem uma passagem final incremental sem tempo de inatividade. Planeje uma transição controlada e confirme a compatibilidade da versão de origem e o procedimento final de congelamento de gravação com o suporte do ownCloud antes de usar o sistema em produção.

Os passos abaixo seguem o guia oficial de migração do ownCloud Server 11.0 e a documentação de autenticação e backup do Infinite Scale 8.2, disponíveis em 6 de outubro de 2026. A sintaxe dos comandos, as variáveis ​​de ambiente e os termos de suporte podem sofrer alterações; confirme-os consultando a documentação da sua versão instalada.

Etapa 1: Faça um inventário da instância Clássica e defina o que significa "migrada".

Para o Cedar Studio, a primeira tarefa é listar usuários, grupos, contas habilitadas e desabilitadas, pastas compartilhadas, links de compartilhamento, montagens externas e quaisquer usuários locais que não existam no LDAP. Registre quais equipes dependem de cada item. Isso evita que uma transferência bem-sucedida de arquivos pessoais seja interpretada como prova de que todos os fluxos de trabalho antigos foram migrados.

De acordo com o guia de migração, a migração pode transferir usuários e grupos habilitados com suas respectivas associações, os arquivos do diretório pessoal de cada usuário habilitado e os compartilhamentos de usuários, grupos e links. Os arquivos são colocados no Espaço pessoal de cada usuário no oCIS. Usuários desabilitados e seus arquivos são ignorados. O processo não migra senhas ou montagens externas. Os bytes residentes em montagens externas e compartilhamentos recebidos são excluídos da transferência de arquivos pessoais e devem ser tratados separadamente. Inventarie esses locais e atribua um responsável pela migração manualmente.

Registre também se links públicos sem senha estão em uso. Por padrão, oCIS exige senha para links públicos; esses links clássicos podem não ser migrados, a menos que a política de destino seja alterada. Não enfraqueça essa política apenas para preservar URLs antigos. Decida se os proprietários dos links devem criar novos links protegidos por senha. As senhas dos links migrados protegidos por senha não corresponderão às senhas antigas, portanto, os usuários devem redefini-las após a migração.

Etapa 2: Prepare um destino oCIS limpo e a conexão de migração.

Crie e teste uma instância separada do oCIS antes de transferir os dados de produção. O guia de migração exige que ambos os sistemas estejam em execução e acessíveis entre si. Ele também alerta que o ambiente de destino deve ser novo e limpo: usuários ou dados preexistentes podem entrar em conflito com o conteúdo importado. Faça backup da instância Classic atual e prepare um plano de reversão que a mantenha disponível até que os usuários aceitem o novo serviço.

A migração requer um aplicativo fornecido pelo ownCloud instalado no servidor Classic. Ele é fornecido como parte de uma migração guiada; a documentação orienta os administradores a entrarem em contato com o suporte do ownCloud para obtê-lo. O aplicativo inclui seu próprio binário rclone. Não substitua o processo documentado deste aplicativo por um pacote aleatório do Marketplace ou por uma tarefa de cópia de arquivos não relacionada.

No lado do oCIS, habilite o auth-appserviço e a configuração de autenticação do aplicativo. O guia de migração também exige que a representação esteja ativa e que um token de aplicativo seja criado para o administrador do oCIS. A documentação do aplicativo de autenticação do Infinite Scale 8.2 afirma explicitamente que a representação destina-se à migração e não deve permanecer habilitada em um ambiente de produção. Trate-a como uma configuração temporária de migração: proteja o token, limite quem pode acessá-lo e desative a representação somente para migração após a conclusão do trabalho. Em uma implantação distribuída, aplique as configurações ao serviço correto, conforme especificado na documentação.

Para o hipotético Cedar Studio, o alvo oCIS deve ser testado com o mesmo serviço LDAP usado pelo servidor Classic. Mantenha as credenciais no mecanismo secreto da implantação, em vez de colar senhas de vinculação no histórico do shell ou em um runbook compartilhado. O guia oficial de migração do ownCloud lista os requisitos do alvo e indica o suporte do ownCloud para o aplicativo de migração. O guia do aplicativo de autenticação oCIS 8.2 explica os tokens de aplicativo e a representação de usuário.

Etapa 3: Garanta a consistência do mapeamento de identidades e, em seguida, execute as verificações de prontidão.

O oCIS precisa conseguir resolver os usuários e grupos antes que seus arquivos e compartilhamentos sejam migrados. O Cedar Studio já usa LDAP, então seu administrador conectaria o oCIS ao mesmo diretório, verificaria se os usuários conseguem fazer login e se os identificadores correspondem às contas desejadas. O guia do ownCloud indica endereços de e-mail únicos e válidos para cada usuário Classic habilitado. Para usuários Classic com suporte LDAP, ele também indica o atributo de nome de usuário, geralmente `username` uidou ` samAccountNameusername`, e as configurações correspondentes do esquema LDAP do oCIS. Certifique-se de que os atributos correspondam ao diretório real; não copie valores de exemplo cegamente.

Se o Classic usar contas locais, mas o oCIS usar um diretório LDAP externo, crie ou migre os usuários e grupos correspondentes para esse diretório antes da transferência de arquivos. Os nomes de usuário e grupo devem ser iguais. O IDM interno do oCIS é um diretório incorporado limitado, destinado a pequenas configurações ou testes; a ownCloud recomenda um LDAP real ou um sistema de gerenciamento de identidade externo para produção. O procedimento oficial de migração não oferece suporte a uma população mista de usuários do Classic com contas locais e LDAP em um mesmo ramo de migração. Resolva essa arquitetura com o suporte em vez de improvisar no meio do processo.

Após a instalação e ativação do aplicativo de migração no Classic, adapte o caminho e a conta de serviço documentados à sua instalação. O guia usa `path` e `conta de serviço` /var/www/owncloudcomo www-dataexemplos:

sudo -u www-data php /var/www/owncloud/occ app:enable migrate_to_ocis
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:init ocis.example.com
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:verify

O comando de verificação verifica se os usuários habilitados possuem endereços de e-mail válidos e não duplicados. Corrija os problemas relatados antes de prosseguir, em vez de ignorar a verificação. Se um usuário desabilitado precisar ser migrado, revise a conta, habilite-a no Classic antes da verificação e inclua-a no plano de migração. O Cedar Studio também deve verificar o login LDAP no oCIS com vários usuários representativos antes do início da transferência de dados.

Etapa 4: Conclua a ramificação de usuários e grupos e, em seguida, migre os arquivos e compartilhamentos.

Siga o caminho indicado no guia oficial que corresponde à sua configuração de identidade. Se os usuários do Classic forem locais e utilizarem o IDM integrado do oCIS, a sequência do guia inclui a migração de usuários, a atribuição de uma função no oCIS e a migração de grupos. Uma função é atribuída aos usuários migrados; as funções do Classic não são preservadas integralmente e os privilégios de subadministrador do Classic não têm função equivalente no oCIS. Revise o acesso administrativo manualmente. Se ambos os sistemas utilizarem o mesmo diretório LDAP, certifique-se de que os usuários e grupos já estejam disponíveis para o oCIS e siga o caminho indicado pelo LDAP em vez de criar duplicatas.

Após usuários, grupos e funções estarem prontos, os comandos documentados para arquivos e compartilhamentos utilizam o nome de usuário do administrador do oCIS como argumento final. A senha do administrador do Classic é solicitada interativamente:

sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:files admin
sudo -u www-data php /var/www/owncloud/occ migrate:to-ocis:migrate:shares admin

Execute a transferência de arquivos antes da transferência de compartilhamentos, conforme descrito no procedimento de migração. Usuários que nunca fizeram login e não possuem arquivos, ou usuários ausentes do oCIS, são ignorados na etapa de transferência de arquivos. Compartilhamentos que envolvem usuários ou grupos ausentes podem ser relatados como erros durante a migração. Para o Cedar Studio, isso significa que a equipe deve inspecionar a saída do comando e o inventário de compartilhamentos; a conclusão sem uma falha crítica não é garantia de que todos os compartilhamentos funcionam.

O guia de migração afirma que as etapas bem-sucedidas não podem ser simplesmente repetidas sem antes remover os dados de destino criados. Uma --forcereinicialização da inicialização não remove os arquivos já migrados do oCIS. Não use sinalizadores de reinicialização como uma estratégia de repetição de rotina. Se uma etapa falhar, preserve os registros, identifique o que foi criado e consulte o guia de migração ou o suporte antes de decidir se deve reparar o destino ou reiniciar em um novo.

Etapa 5: Faça a transição com uma janela de validação e recuperação bem definida.

Para uma transição segura, a Cedar Studio agendaria um período em que os funcionários parariam de editar arquivos no Classic, executariam a migração aprovada e, somente após as verificações serem concluídas, direcionariam os clientes e usuários para o oCIS. Esse congelamento de gravações é uma medida de segurança operacional, não uma garantia de que o aplicativo de migração realiza sincronização em tempo real. O guia de migração publicado não documenta a sincronização contínua nem um comando final de cópia delta. Se a empresa não puder tolerar um congelamento de gravações, entre em contato com o suporte do ownCloud para obter um plano de transição específico para a versão antes de prometer uma migração sem interrupções.

Valide com uma lista de verificação em vez de um único login de administrador:

• Confirme se os usuários, grupos e associações de grupo habilitados esperados aparecem no oCIS; confirme as atribuições de função, especialmente para ex-administradores.
• Solicite aos usuários que abram arquivos migrados representativos de vários Espaços pessoais, incluindo arquivos grandes e documentos editados recentemente.
• Teste o compartilhamento interno de usuários e o compartilhamento em grupo tanto com a conta proprietária quanto com a conta destinatária.
• Abra links públicos em uma sessão de navegador privada; redefina as senhas de links protegidos migrados e recrie links que não passaram nas verificações de política.
• Recrie os pontos de montagem externos e migre ou reconecte separadamente os dados aos quais eles apontavam e, em seguida, confirme se os usuários têm o acesso pretendido.
• Antes de anunciar o novo endereço, verifique os aplicativos para desktop e dispositivos móveis, o processo de login, a sincronização e o canal de suporte para redefinição de senha.

Mantenha o Classic disponível em um estado controlado de somente leitura ou congelado até que o proprietário da empresa aprove e os registros necessários sejam verificados. Remova a capacidade de representação temporária e revogue o token do aplicativo de migração quando não for mais necessário. Em seguida, faça um backup do oCIS e teste-o usando o procedimento para seu layout de armazenamento. As considerações oficiais de backup do oCIS 8.2 indicam que a instância deve ser completamente desligada para o procedimento de backup documentado e explicam que metadados e blobs de arquivos podem ter caminhos de armazenamento separados.

Como é uma migração bem-sucedida?

No exemplo do Cedar Studio, o sucesso não se resume apenas ao carregamento da interface web do oCIS. Significa que os funcionários conseguem autenticar-se com a fonte de identidade pretendida, encontrar o conteúdo do seu diretório pessoal, abrir arquivos de equipe e usar compartilhamentos recriados ou migrados com as permissões esperadas. Redefinições de senha, montagens externas e alterações de links públicos são consideradas, enquanto o Classic permanece disponível até a aceitação. Se alguma dessas verificações falhar, a transição deve ser pausada, os usuários e objetos afetados devem ser registrados e a falha resolvida antes de se considerar o oCIS como o sistema oficial.