Die UrBackup-Installation aus der Quelle schlug aus mehreren unabhängigen Gründen fehl, bevor sie funktionierte: Der Image-Pull wurde über einen ausschließlich für das chinesische Festland bestimmten Mirror umgeleitet, die ersten Bind-Pfade waren auf dem ZimaOS-Host nicht vorhanden, die Berechtigungen für das Backup-Verzeichnis waren falsch und die URL bzw. die Ports des App-Launchers sorgten für Verwirrung.
Die dauerhafte Erkenntnis besteht darin, UrBackup wie eine normale zustandsbehaftete Docker-Anwendung zu behandeln: Verwenden Sie echte Host-Speicherpfade, speichern Sie sowohl Backupdaten als auch die UrBackup-Datenbank bzw. den Status dauerhaft, überprüfen Sie die Berechtigungen des Laufzeitbenutzers und bestätigen Sie die WebUI-/Netzwerk-Listener, bevor Sie sich für Client-Backups darauf verlassen.
Der erste Image-Pull wurde in einen nicht nutzbaren Mirror umgeschrieben
Der Daemon gab eine Meldung über verweigertes Abrufen für docker.1panel.live/uroni/urbackup-server. Die offizielle UrBackup-Downloadseite nennt weiterhin uroni/urbackup-server als offizielles Docker-Image.
Siehe das aktuelle offizielle UrBackup-Docker-Image.
Bind-Mounts müssen auf echte ZimaOS-Hostordner verweisen
Die funktionierende Zusammenfassung verwendete echten Speicher unter Pfaden wie /media/Safe-Storage/UrBackup/backups und /media/Safe-Storage/UrBackup/data, zugeordnet zu /backups und /var/urbackup. Überprüfen Sie Ihren tatsächlichen Hostpfad, anstatt den Speichernamen der Quelle wörtlich zu kopieren.
„Permission Denied“ bedeutet, dass der Containerbenutzer nicht schreiben kann
Die Quelle stieß auf Keine Berechtigung für den Zugriff auf „/backups/urbackup_tmp_files“. Die Korrektur verwendete eine spezifische UID/GID und passende Besitzrechte auf dem Host. Nicht festlegen 1000:100 als universelle Identität; überprüfen Sie den aktuellen Laufzeitbenutzer.
Sowohl Backups als auch den UrBackup-Status dauerhaft speichern
Das Repository enthält Client-Backupdaten, während /var/urbackup enthält die Serverdatenbank und den Status. Ein brauchbarer Wiederherstellungsplan sollte beides angemessen sichern.
Die Quelle verwendete Host-Netzwerk
Das gepflegte uroni/urbackup-server Das Image dokumentiert derzeit Host-Netzwerk als ein unterstütztes Docker-Muster und stellt die normalen UrBackup-Dienstports bereit. Host-Netzwerk vereinfacht die Erkennung, hebt jedoch die Docker-Netzwerkisolierung auf.
Die WebUI benötigt den richtigen Port
Die Quelle korrigierte den ZimaOS-Launcher auf Port 55414. Der Launcher ist nur eine praktische URL; der tatsächliche Dienststatus sollte anhand von Protokollen und Listenern überprüft werden.
Eine reproduzierbare Compose-Definition bevorzugen
Der aktuelle ZimaOS App Store 2.0 und Workflows für benutzerdefinierte Apps unterstützen standardmäßiges Docker Compose. Bewahren Sie Image, persistente Pfade, Zeitzone, Neustart-Richtlinie und Netzwerk in einer gemeinsamen Compose-Definition auf.
Verwenden Sie das aktuelle ZimaOS-Compose-Modell.
Ein laufendes Dashboard ist nicht der abschließende Test
Registrieren Sie einen Client, führen Sie eine kleine Sicherung durch, starten Sie den Container bzw. Host neu und stellen Sie anschließend eine Datei wieder her. Dadurch werden Netzwerk, Berechtigungen, Persistenz der Datenbank und Sicherungsspeicher gemeinsam überprüft.
Legen Sie das Sicherungs-Repository auf einem Datenspeicher ab, nicht auf dem Systemlaufwerk
UrBackup kann Hunderte Gigabyte oder mehr belegen. Der Repository-Pfad sollte auf einen tatsächlichen ZimaOS-Speicherort mit bekannter Kapazität und bekanntem Zustand verweisen, nicht auf das kleine Betriebssystemlaufwerk.
Bestätigen Sie vor dem Hinzufügen von Clients den Hostpfad in ZimaOS und beobachten Sie den freien Speicherplatz während der ersten vollständigen Sicherung.
Die UrBackup-Datenbank ist Teil des Wiederherstellungssystems
Die Dateien unter /backups sind nur eine Hälfte eines nutzbaren Servers. Der Zustand und die Datenbank von UrBackup unter /var/urbackup verfolgt Clients, Sicherungsmetadaten, Aufbewahrung und die Serverkonfiguration.
Dokumentieren und schützen Sie beide persistenten Zuordnungen, damit eine Neuerstellung des Containers nicht dazu führt, dass sich zahlreiche Sicherungsdateien ohne den erwarteten Serverzustand ansammeln.
Verwenden Sie Schreibzugriff nach dem Prinzip der geringsten Berechtigung
Die quellenspezifische Anpassung von UID/GID hat eine Bereitstellung behoben, doch rekursive Änderungen der Eigentümer auf einem gesamten Speicherpool sind riskant. Erstellen Sie ein eigenes UrBackup-Verzeichnis und gewähren Sie der Container-Identität Zugriff auf dieses Verzeichnis, statt uneingeschränkten Schreibzugriff auf nicht zugehörige NAS-Daten zu gewähren.
Das Host-Netzwerk setzt UrBackup-Dienste direkt auf ZimaOS frei
Wenn das Host-Netzwerk verwendet wird, sind die UrBackup-Listener direkt auf dem Host aktiv. Wenn ZFW oder eine andere Firewall das NAS schützt, erlauben Sie nur die für Sicherung und Erkennung erforderlichen Ports und Clientnetzwerke. Veröffentlichen Sie UrBackup-Dienstports nicht direkt im öffentlichen Internet.
Testen Sie eine Wiederherstellung, bevor Sie den Backup-Server als fertig betrachten
Führen Sie eine vollständige Client-Sicherung durch, starten Sie ZimaOS neu oder erstellen Sie den Container neu, überprüfen Sie, ob der Clientverlauf erhalten bleibt, und stellen Sie anschließend mehrere Dateien an einem separaten Speicherort wieder her. Dadurch werden die Verfügbarkeit des Images, Berechtigungen, der persistente Zustand, das Netzwerk und die tatsächliche Wiederherstellbarkeit überprüft – nicht nur das grüne Dashboard.
UrBackup-FAQ für ZimaOS
Hat der Benutzer der Quelle UrBackup letztendlich zum Laufen gebracht?
Ja.
Sollte jedes ZimaOS-System PUID 1000 und PGID 100 verwenden?
Nein. Das waren quellenspezifische Werte.
Ist das Host-Netzwerk zwingend erforderlich?
Nicht universell. Es handelt sich um eine dokumentierte Image-Option, die von der Quelle erfolgreich verwendet wurde, jedoch die Netzwerkisolierung verringert.
