Revisado em 6 de outubro de 2026. Se a pesquisa do Zimbra retornar resultados incompletos para uma caixa de correio e o log da caixa de correio apontar para um erro de indexador ou do Lucene, a solução usual é reconstruir o índice de pesquisa dessa caixa de correio com o comando `zimbra search index` zmprov rim account@example.com start. Esse comando recria os dados de índice pesquisáveis a partir do conteúdo da caixa de correio; ele não corrige arquivos de mensagens ausentes, corrupção do banco de dados, volume de armazenamento cheio ou falhas de pesquisa em todo o servidor.
Avalie o sucesso pelo resultado concreto: a reindexação é concluída, as buscas direcionadas retornam mensagens que estavam ausentes anteriormente e novos e-mails continuam aparecendo nos resultados de busca. Iniciar o comando não comprova que o índice foi reconstruído. Planeje a execução do comando para um período de menor movimento, verifique o volume do índice primeiro e execute-o para uma conta afetada antes de expandir o escopo.
Quando a reindexação da caixa de correio é a solução adequada?
Um índice danificado ou incompleto é uma causa provável quando o acesso normal à caixa de correio funciona, mas as pesquisas não encontram mensagens conhecidas, o usuário afetado vê resultados de pesquisa inconsistentes ou /opt/zimbra/log/mailbox.logrecebe mensagens como "Falha ao abrir o indexador" ou uma exceção do Lucene para essa conta. O material de solução de problemas do Zimbra documenta isso zmprov verifyIndexcomo um diagnóstico para um índice ausente ou que não pode ser aberto e utiliza métodos zmprov rim ... startpara recriá-lo.
Primeiro, determine o escopo. Se apenas um usuário for afetado, investigue essa caixa de correio. Se muitos usuários no mesmo repositório de e-mails apresentarem o mesmo sintoma, verifique a integridade do servidor, a capacidade de armazenamento, as atualizações recentes e os logs antes de iniciar várias reconstruções. Um grande lote de reindexações pode consumir recursos substanciais de E/S de disco e CPU, além de piorar a lentidão nas buscas para outros usuários.
Reindexar não é a primeira medida correta quando os usuários não conseguem fazer login, pastas estão faltando, o corpo das mensagens ou anexos não abrem, o banco de dados do armazenamento de e-mails relata erros ou o serviço de busca está indisponível para várias contas. Esses sinais podem indicar problemas no banco de dados, no armazenamento de blobs, no serviço ou na infraestrutura. Preserve os registros e use o procedimento de recuperação ou o canal de suporte apropriado do Zimbra, em vez de tratar todas as reclamações de "busca" como corrupção de índice.
Antes de executar o comando
- Confirme a caixa de correio de destino: copie o endereço da conta principal, não um alias. Em uma implantação com vários servidores de correio, verifique qual servidor de correio é o proprietário da conta e execute o comando de acordo com sua topologia e versão do Zimbra instalada.
- Verifique o espaço disponível: Inspecione o espaço livre e os inodes no volume de índice real. As instalações podem colocar os dados de índice em um ponto de montagem separado; não assuma que o caminho padrão seja o local ativo. Um volume de índice cheio pode, por si só, causar falhas de indexação.
- Verifique a carga do sistema: observe a latência atual do servidor de e-mail, o uso da CPU e a atividade do disco. A reindexação consome muitos recursos, principalmente para caixas de correio grandes, portanto, agende-a para horários fora dos picos de tráfego.
- Proteja a capacidade de recuperação: antes de realizar qualquer manutenção, certifique-se de que o processo de backup normal esteja íntegro e atualizado. A reindexação visa reconstruir os dados de pesquisa derivados, mas um backup continua sendo essencial antes de qualquer reparo em e-mails de produção.
- Verifique a compatibilidade de comandos: a sintaxe da CLI do Zimbra e as opções disponíveis podem variar conforme a versão. Consulte a ajuda e a documentação dos comandos para obter informações específicas sobre a versão instalada, principalmente se estiver usando uma versão antiga ou uma implantação personalizada.
Como verificar e reconstruir uma caixa de correio
1. Execute uma verificação de diagnóstico, se disponível.
Como usuário do sistema operacional Zimbra, teste a caixa de correio suspeita com o diagnóstico mostrado no guia de solução de problemas do Zimbra:
zmprov verifyIndex user@example.com
Uma resposta indicando que o índice não existe ou que um arquivo de segmento não foi encontrado confirma o diagnóstico de corrupção do índice. Se a sua versão instalada não reconhecer o índice verifyIndex, não instale scripts nem copie arquivos de índice de outro servidor para contornar o problema. Consulte a documentação específica da versão do Zimbra e correlacione o log da caixa de correio com a conta afetada.
2. Inicie a reindexação da caixa de correio.
No servidor Zimbra apropriado, acesse a conta do sistema operacional Zimbra e inicie a reconstrução da caixa de correio afetada:
su - zimbra
zmprov rim user@example.com start
O comando normalmente informa que a tarefa foi iniciada. Isso confirma o envio, não a conclusão. Não inicie tarefas repetidas apenas porque a pesquisa permanece incompleta imediatamente depois; primeiro verifique o estado da tarefa e os registros do repositório de e-mails.
3. Verificar progresso
Consulte a tarefa de reindexação usando a mesma conta e o mesmo contexto de servidor:
zmprov rim user@example.com status
Repita o comando em intervalos razoáveis, em vez de consultar continuamente. Leia a resposta de acordo com a sua versão do Zimbra: a CLI reporta o estado da tarefa, enquanto o comando mailbox.logpode fornecer o progresso ou erros específicos da conta. Se o comando reportar um erro, a tarefa nunca for concluída ou os logs mostrarem falhas de espaço em disco ou de gravação de índice, pause o comando e resolva o problema subjacente antes de tentar novamente.
A lista de comandos do Zimbra reIndexMailboxinclui as ações `send` start, status`send` e `send` cancel. Se a sua versão suporta cancelamento e a tarefa está prejudicando o serviço, confirme a sintaxe local antes de usá-la. Não encerre processos Java nem remova arquivos de índice como substituto para um procedimento de cancelamento suportado.
Como confirmar se o reparo funcionou
Após a conclusão da tarefa, teste a partir do cliente web do usuário afetado com algumas mensagens conhecidas. Busque por um remetente, assunto e intervalo de datas distintos; verifique tanto mensagens antigas quanto recentes. Confira as pastas onde as mensagens deveriam aparecer e compare o resultado com uma mensagem conhecida que o usuário possa abrir diretamente. Em seguida, envie ou receba uma mensagem de teste e confirme se ela se torna pesquisável após o atraso normal de indexação.
Busque uma melhoria contínua em vez de uma única consulta bem-sucedida. Os critérios práticos de sucesso são:
- O status de reindexação da caixa de correio foi concluído sem erros recorrentes.
- Mensagens anteriormente ausentes, agora conhecidas, aparecem nas buscas esperadas.
- Novos e-mails continuam a entrar no índice de pesquisa.
- O volume de indexação mantém capacidade livre adequada e as demais caixas de correio eletrônico permanecem responsivas.
Se o comando reportar conclusão, mas mensagens específicas continuarem ausentes, verifique se as mensagens ainda existem e podem ser abertas. Verifique se os termos de pesquisa do usuário, os filtros de data, o escopo da pasta ou o cache do lado do cliente explicam a diferença. Um índice reconstruído não pode restaurar mensagens que foram excluídas, nunca entregues ou perdidas do armazenamento subjacente.
Quando alterar o caminho de resolução de problemas
Se a reconstrução falhar repetidamente, primeiro resolva o erro mencionado nos logs. Confirme o espaço em disco e os inodes disponíveis, verifique se há erros mais abrangentes no armazenamento de e-mails ou no banco de dados e certifique-se de que a caixa de correio esteja sendo gerenciada no servidor correto. Se a conta não conseguir acessar o conteúdo das mensagens ou se outras caixas de correio apresentarem o mesmo problema, interrompa a repetição da reindexação e investigue a causa no armazenamento, no banco de dados ou no servidor.
Evite excluir /opt/zimbra/indexdados manualmente como procedimento de rotina. O wiki público do Zimbra inclui um procedimento para remoção manual de arquivos de índice, mas essa página está marcada como em desenvolvimento e vinculada a versões antigas. A exclusão manual é mais propensa a erros do que o comando de reindexação em nível de conta, que é suportado, e só deve ser considerada sob as orientações atuais do fornecedor, específicas para a versão em questão, com o caminho exato da caixa de correio, backups verificados e um plano de manutenção.
Limitações da reindexação de caixas de correio
A reindexação reconstrói os metadados de pesquisa; ela não repara tabelas MySQL ou MariaDB, não restaura blobs ausentes, não corrige um sistema de arquivos danificado, não libera espaço em disco nem resolve uma interrupção geral da pesquisa no servidor. Além disso, o processo leva mais tempo à medida que o tamanho da caixa de correio e a carga do servidor aumentam. A pesquisa pode ficar temporariamente incompleta durante a indexação, e o desempenho geral pode cair durante essa tarefa.
Use primeiro a reindexação integrada ao nível da caixa de correio quando as evidências apontarem para o índice de pesquisa de uma conta. Meça o resultado usando mensagens conhecidas e e-mails subsequentes. Se a reindexação não puder ser concluída ou se os próprios dados estiverem corrompidos, passe para o procedimento de recuperação de armazenamento ou banco de dados relevante, em vez de recorrer à exclusão completa do índice.
Referências oficiais