Erfahrungen bei der Migration des Baikalservers (0.9.3. auf 0.9.5)

[Gerdfs]

Hallo,

ich möchte mich in erster Linie mal bedanken für die ausführliche Anleitung, die ich oft und immer wieder studiere, das ist ja eine Menge Arbeit das aufzuschreiben. Daher ist das auch kein Issue, eher eine Rückmeldung (ich kann nur keine andere Kategorie als Issue auswählen).

Ich hatte einige Zeit einen Baikal Server nach Anleitung auf meinem NAS aufgesetzt und der lief auch reibungslos. Ich konnte bis auf 0.9.3 updaten, auf 0.9.5 habe ich versucht, das ging leider nicht, weil mein NAS (Openmediavault) noch ein älteres debian mit php 7 statt php 8 hat. War vermutlich ein Fehler.

Da mein NAS nicht ständig läuft (es wird per Wake-on-LAN geweckt, wenn sich bestimmte Clients einschalten, wenn die inaktiv sind geht es in Standby) gab es immer mal wieder Fehlermeldungen von DAVx5 auf den Android Clients des Baikal Servers. Aber keinen Datenverlust. Daher wollte ich den Baikal Server auf ein raspi 4, welches 24/7 läuft umziehen.

Auf dem raspi habe ich dann Baikal 0.9.5. installiert. Am Umzug der Daten bin ich leider gescheitert und habe letztendlich einen Datenverlust erlitten. Ich habe versucht einige Dateien zu kopieren, es gibt ja auch unter https://github.com/sabre-io/Baikal einige Issues die sich mit dem Backup der Datenbank beschäftigen, wobei vorgeschlagen wird bestimmte .php Dateien zu kopieren und die sqlite Datenbank zu sichern und zu restaurieren.

Die Strategie, nur ausgewälte Dateien zu kopieren hat leider zu Fehlermeldungen der Weboberfläche auf dem raspi 4 geführt. Auch konnte ich einige in den Beiträgen genannte Dateien gar nicht finden.

Das Kopieren der Datenbank hat ebenfalls zu Fehlermeldungen geführt, sichern per sqlite3 db.sqlite .dump | gzip -c > db.dump.gz hat funktioniert, rücksichern auf dem raspi 4 per sudo zcat db.dump.gz | sqlite3 db.sqlite hat zu einer Fehlermeldung geführt.

Ich muss dazu sagen, dass ich vorher auch kein Backup gemacht habe, Dein Vorschlag, das ganze Baikal Verzeichnis zu sichern und zu kopieren ist daran gescheitert, dass der Befehl zum rekursiven zippen des Ordners Fehlermeldungen geworfen hat, in die Richtung dass die Links nicht aufzulösen sind.

Meine Idee, einfach den Datenstand auf einem Client dem neuen Baikal Server "unterzujubeln" ist leider auch gescheitert, weil die Änderung der Serveradresse in DAVx5 nicht vorgesehen ist. Man muss das ganze Konto löschen und sich neu verbinden. Leider sind dadurch die Daten lokal dann weg.

Dann hatte ich über die Web-Anwenderoberfläche des "alten" Baikals vor der Migration den Kalender als .ics und die Kontakte als .vcf Dateien gespeichert. Die .vcf Datei war ok, in der +.ics Datei hat leider die Hälfte gefehlt. Termine aus 2019 waren da, Termine aus 2024 nicht mehr.

Kurzum, wahrscheinlich habe ich mich ungeschickt angestellt oder die Versionen (php, sqlite, Baikal) von 0.9.3 auf 0.9.5 waren dummerweise inkompatibel. Letztendlich habe ich einige Stunden "verbraten" und war schon geneigt den bequemen Weg der Syncronisation mit Google zu gehen.

Letztendlich läuft der neue Server wieder, aber sich sollte mir wohl Gedanken um ein regelmäßiges Backup machen. Meine diffuse Backupstrategie, dass ich ja eigentlich die Daten auf vielen Clients redundant vorliegen habe und bei Serverausfall drauf zurückgreifen kann ist ja nicht aufgegangen.

Grüße, Gerd

[JsBergbau]

Hallo Gerd,

danke für deine Erfahrungen.

Das ist sehr ärgerlich, dass es bei dir zu einem Datenverlust gekommen ist.
Eventuell hat sich bei dir ein Dateisystemfehler eingeschlichen.
sudo tar czf Baikal.tar.gz Baikal funktioniert bei mir problemlos um das Dateisystem zu sichern.

Das nicht immer verfügbare NAS ist kein Problem. Ich greife nur via VPN zu und unterwegs ist das VPN häufig gar nicht aktiv. Die Daten werden dann synchronisiert, wenn das VPN zur Verfügung steht.

Ich sichere übrigens einmal täglich den kompletten Inhalt des Raspberr PIs mit restic (mit Ausnahme einiger weniger Verzeichnisse wie caches). Damit lässt sich dann das gesamte System zu jedem beliebigen Stand wiederherstellen. Das habe ich schon mehrmals durchgespielt und auch einmal schon gebraucht, weil ein fehlerhafter Raspberry PI das Dateisystem auf einer SSD zerstört hatte.