L’installazione di UrBackup dalla fonte non è riuscita per diverse ragioni indipendenti prima di funzionare: il pull dell’immagine è stato riscritto tramite un mirror disponibile solo nella Cina continentale, i primi percorsi bind non esistevano sull’host ZimaOS, i permessi della directory dei backup erano errati e l’URL e le porte del launcher dell’app erano fonte di confusione.
La lezione duratura è trattare UrBackup come una normale applicazione Docker con stato: utilizza percorsi di storage reali sull’host, rendi persistenti sia i dati dei backup sia il database e lo stato di UrBackup, verifica i permessi dell’utente di runtime e conferma i listener della WebUI e della rete prima di affidargli i backup dei client.
Il primo pull dell’immagine è stato riscritto verso un mirror inutilizzabile
Il daemon ha restituito un messaggio di pull negato per docker.1panel.live/uroni/urbackup-server. La pagina di download ufficiale di UrBackup identifica ancora uroni/urbackup-server come immagine Docker ufficiale.
Vedi l’immagine Docker ufficiale attuale di UrBackup.
I bind mount devono puntare a cartelle reali dell’host ZimaOS
Il riepilogo funzionante utilizzava storage reale in percorsi come /media/Safe-Storage/UrBackup/backups e /media/Safe-Storage/UrBackup/data, mappati su /backups e /var/urbackup. Controlla il percorso effettivo sull’host invece di copiare alla lettera il nome dello storage della fonte.
“Permission Denied” significa che l’utente del container non può scrivere
La fonte ha restituito Nessuna autorizzazione per accedere a "/backups/urbackup_tmp_files". La sua correzione utilizzava uno UID/GID specifico e la proprietà corrispondente sull’host. Non fissare 1000:100 come identità universale; verifica l’utente di runtime attuale.
Mantieni sia i backup sia lo stato di UrBackup
Il repository contiene i dati dei backup dei client, mentre /var/urbackup contiene il database e lo stato del server. Un piano di ripristino utilizzabile dovrebbe preservare entrambi, secondo necessità.
La fonte utilizzava la rete dell’host
Il mantenuto uroni/urbackup-server image documenta attualmente la rete dell’host come uno dei pattern Docker supportati ed espone le normali porte del servizio UrBackup. La rete dell’host semplifica l’individuazione, ma elimina l’isolamento della rete Docker.
La WebUI richiede la porta corretta
La fonte ha corretto il launcher di ZimaOS sulla porta 55414. Il launcher è solo un URL di comodo; lo stato effettivo del servizio dovrebbe essere verificato tramite i log e i listener.
Preferisci una definizione Compose riproducibile
L'App Store 2.0 attuale di ZimaOS e i flussi di lavoro per le app personalizzate supportano Docker Compose standard. Mantieni l'immagine, i percorsi persistenti, il fuso orario, la policy di riavvio e la rete in un'unica definizione Compose.
Usa il modello Compose attuale di ZimaOS.
Un dashboard operativo non è il test finale
Registra un client, completa un piccolo backup, riavvia il container o l'host, quindi esegui un ripristino di file. In questo modo verifichi contemporaneamente rete, autorizzazioni, persistenza del database e archiviazione dei backup.
Posiziona il repository dei backup nello spazio di archiviazione dei dati, non sul disco di sistema
UrBackup può consumare centinaia di gigabyte o più. Il percorso del repository deve puntare a uno spazio di archiviazione ZimaOS reale, con capacità e stato noti, non alla piccola unità del sistema operativo.
Prima di aggiungere i client, verifica il percorso dell'host in ZimaOS e controlla lo spazio libero durante il primo backup completo.
Il database di UrBackup fa parte del sistema di ripristino
I file in /backups sono solo metà di un server utilizzabile. Lo stato e il database di UrBackup in /var/urbackup tiene traccia dei client, dei metadati dei backup, della conservazione e della configurazione del server.
Documenta e proteggi entrambe le mappature persistenti, in modo che la ricreazione di un container non lasci una pila di file di backup senza lo stato previsto del server.
Usa i permessi di scrittura minimi necessari
La modifica UID/GID specifica della fonte ha risolto un'installazione, ma le modifiche ricorsive della proprietà sull'intero pool di archiviazione sono rischiose. Crea una directory UrBackup dedicata e concedi all'identità del container l'accesso a tale directory, invece di concedere ampi permessi di scrittura a dati NAS non correlati.
La modalità di rete dell'host espone direttamente i servizi UrBackup su ZimaOS
Quando viene utilizzata la modalità di rete dell'host, i listener di UrBackup sono listener dell'host. Se ZFW o un altro firewall protegge il NAS, consenti solo le porte e le reti client necessarie per il backup e il rilevamento. Non pubblicare direttamente su Internet le porte dei servizi UrBackup.
Testa un ripristino prima di considerare completato il server di backup
Completa il backup di un client, riavvia ZimaOS o ricrea il container, verifica che la cronologia del client sia rimasta, quindi ripristina diversi file in una posizione separata. In questo modo vengono validate la disponibilità dell'immagine, le autorizzazioni, lo stato persistente, la rete e l'effettiva possibilità di ripristino, non solo il dashboard verde.
FAQ su UrBackup in ZimaOS
L'utente della fonte è riuscito alla fine a far funzionare UrBackup?
Sì.
Ogni sistema ZimaOS dovrebbe usare PUID 1000 e PGID 100?
No. Erano valori specifici della fonte.
La modalità di rete dell'host è obbligatoria?
Non universalmente. È un'opzione dell'immagine documentata e la fonte l'ha utilizzata con successo, ma riduce l'isolamento di rete.
