A instalação do UrBackup da fonte falhou por vários motivos independentes antes de funcionar: a extração da imagem foi reescrita através de um espelho disponível apenas na China continental, os primeiros caminhos bind não existiam no anfitrião ZimaOS, as permissões do diretório de cópias de segurança estavam incorretas e o URL/as portas do iniciador da aplicação eram confusos.
A lição duradoura é tratar o UrBackup como uma aplicação Docker normal com estado: utilize caminhos reais de armazenamento no anfitrião, mantenha os dados das cópias de segurança e a base de dados/o estado do UrBackup, verifique as permissões do utilizador de execução e confirme os processos de escuta da WebUI/rede antes de confiar nele para as cópias de segurança dos clientes.
A primeira extração da imagem foi reescrita para um espelho inutilizável
O daemon devolveu uma mensagem de acesso negado ao extrair docker.1panel.live/uroni/urbackup-server. A página oficial de transferências do UrBackup continua a identificar uroni/urbackup-server como imagem Docker oficial.
Consulte a imagem Docker oficial atual do UrBackup.
As montagens bind têm de apontar para pastas reais do anfitrião ZimaOS
O resumo funcional utilizou armazenamento real em caminhos como /media/Safe-Storage/UrBackup/backups e /media/Safe-Storage/UrBackup/data, mapeados para /backups e /var/urbackup. Inspecione o caminho real no anfitrião em vez de copiar literalmente o nome do armazenamento da fonte.
Permissão negada significa que o utilizador do contentor não pode escrever
A fonte encontrou Sem permissão para aceder a "/backups/urbackup_tmp_files". A correção utilizada especificava um UID/GID concreto e a propriedade correspondente no anfitrião. Não fixe 1000:100 como uma identidade universal; verifique o utilizador de execução atual.
Mantenha ambas as cópias de segurança e o estado do UrBackup
O repositório contém dados de cópia de segurança dos clientes, enquanto /var/urbackup contém a base de dados/o estado do servidor. Um plano de recuperação utilizável deve preservar ambos, conforme apropriado.
A fonte utilizou a rede do anfitrião
A versão mantida uroni/urbackup-server A imagem documenta atualmente a rede do anfitrião como um padrão Docker suportado e expõe as portas normais do serviço UrBackup. A rede do anfitrião simplifica a deteção, mas elimina o isolamento da rede Docker.
A WebUI precisa da porta correta
A fonte corrigiu o iniciador do ZimaOS para a porta 55414. O iniciador é apenas um URL de conveniência; o estado real do serviço deve ser verificado através dos registos e dos processos em escuta.
Prefira uma definição Compose reproduzível
A App Store 2.0 atual do ZimaOS e os fluxos de aplicações personalizadas suportam o Docker Compose padrão. Mantenha a imagem, os caminhos persistentes, o fuso horário, a política de reinício e a rede numa única definição do Compose.
Utilize o modelo Compose atual do ZimaOS.
Um painel em execução não é o teste final
Registe um cliente, conclua uma pequena cópia de segurança, reinicie o contentor/anfitrião e, em seguida, execute uma restauração de ficheiros. Isto verifica em conjunto a rede, as permissões, a persistência da base de dados e o armazenamento das cópias de segurança.
Coloque o repositório de cópias de segurança no armazenamento de dados, não no disco do sistema
O UrBackup pode consumir centenas de gigabytes ou mais. O caminho do repositório deve apontar para um espaço de armazenamento real do ZimaOS, com capacidade e estado conhecidos, e não para a pequena unidade do sistema operativo.
Antes de integrar clientes, confirme o caminho do anfitrião no ZimaOS e monitorize o espaço livre durante a primeira cópia de segurança completa.
A base de dados do UrBackup faz parte do sistema de restauração
Os ficheiros em /backups são apenas metade de um servidor utilizável. O estado/base de dados do UrBackup em /var/urbackup controla os clientes, os metadados das cópias de segurança, a retenção e a configuração do servidor.
Documente e proteja ambos os mapeamentos persistentes para que a recriação de um contentor não deixe um amontoado de ficheiros de cópia de segurança sem o estado esperado do servidor.
Utilize acesso de escrita com privilégios mínimos
O ajuste de UID/GID específico da fonte corrigiu uma implementação, mas as alterações recursivas de propriedade em todo um conjunto de armazenamento são arriscadas. Crie um diretório dedicado ao UrBackup e conceda à identidade do contentor acesso a esse diretório, em vez de conceder acesso amplo de escrita a dados não relacionados do NAS.
A rede do anfitrião expõe diretamente os serviços do UrBackup no ZimaOS
Quando é utilizada a rede do anfitrião, os serviços de escuta do UrBackup ficam expostos no anfitrião. Se o ZFW ou outra firewall proteger o NAS, permita apenas as portas e redes de clientes necessárias para a cópia de segurança e a deteção. Não publique diretamente as portas de serviço do UrBackup na Internet pública.
Teste uma restauração antes de considerar concluído o servidor de cópias de segurança
Conclua uma cópia de segurança de um cliente, reinicie o ZimaOS ou recrie o contentor, verifique se o histórico do cliente permanece e, em seguida, restaure vários ficheiros para uma localização separada. Isto valida a disponibilidade da imagem, as permissões, o estado persistente, a rede e a recuperabilidade real — não apenas o painel verde.
FAQ do UrBackup no ZimaOS
O utilizador da fonte acabou por conseguir pôr o UrBackup a funcionar?
Sim.
Todos os sistemas ZimaOS devem utilizar PUID 1000 e PGID 100?
Não. Esses eram valores específicos da fonte.
É obrigatório utilizar a rede do anfitrião?
Não universalmente. É uma opção de imagem documentada que a fonte utilizou com sucesso, mas reduz o isolamento da rede.
