[DISKUSSION] Regelmässiges, automatisches Backup auf Netzwerkresource

[gbglace]

Die Komplexität der direkten Wiederherstellung aus externem medium kann ich mir auch recht hoch vorstellen.
Ich habe ja kein NAS aber wenn ich so drüber nachdenke tät mir da auch schon genügen, wenn die Backups an sich TWS-intern zyklisch automatisiert werden und man diese files dann noch irgendwohin transportieren kann. Bei meinem 2600-er wäre die erste Instanz dann die HDD und die zweite die Sicherung der HDD nach ganz extern. Ob die nächsten Schritte vom Backupsystem aus oder aus einem Auto-Backup-Docker heraus passiert muss ich mir noch überlegen.

Wiederherstellung würde ich auch erstmal nur aus der TWS-internen Datenpartition sehen. braucht dann aber natürlich einen Mechanismus wie man da so ein Backup-Komplettfile von extern wieder rein bekommt. Mit entsprechenden Prüfungen, ist schon da ersetzen oder abbrechen.

Der angesprochene Punkt einer separaten Sicherung der Timeseries Werte inkl. Ringspeicher finde ich nicht uninteressant, ob sowas dann aber auch separat reintegrierbar sein muss sehe ich derzeit noch nicht.

[Sun1453]

Vielleicht müsst ihr gar nicht alles selbst von Null an entwickeln, sondern könnt eine "App" für Docker anbieten, die die Backup-Funktionalität schon mitbringt? Ob das wegen Kapselung und nötigem Zugriff auf TW-interne Ressourcen überhaupt möglich ist, weiß ich nicht.

Hallo Guru,

ich denke das wird wegen des Sicherheitskonzepts, was ich sehr schätze nicht möglich sein.

[Sun1453]

Der angesprochene Punkt einer separaten Sicherung der Timeseries Werte inkl. Ringspeicher finde ich nicht uninteressant, ob sowas dann aber auch separat reintegrierbar sein muss sehe ich derzeit noch nicht.

Wenn man sich das Backup Log des aktuellen Prozesses anschaut, besteht er aus einzelenen Bereichen. Ich denke das dies einzelne Module im Prozess sind, die man auch extra anwählen könnte. Gerade im Wirkbetrieb ändert man ja nicht immer alles und so könnte man sagen das man täglich nur diese Daten sichert. Ein Komplett Backup aber nur 1 mal im Monat oder vor einem Update.

@StefanW Könntest du mal mit dem entsprechenden Entwickler sprechen oder es in das Entwickler Meeting mitnehmen. Dankeschön.

[gurumeditation]

ich denke das wird wegen des Sicherheitskonzepts, was ich sehr schätze nicht möglich sein.

Ich mag Sicherheit und Kapselung auch, aber vielleicht ist das gar kein Widerspruch. Der TWS-interne Backup-Task könnte ja für die Weiterleitung an TWS-externe Ziele (SFTP, AFP, SMB, etc.) die Backup-Dateien in einem lokalen Laufwerk/Ordner ("DMZ") parken, die dann von der App nach extern geschoben werden.

Dafür müsste der interne Backupdienst geringfügig modifiziert^TM werden, damit Konfiguration, Zeitreihen und andere Daten sowie Container-Daten an die Backup-App gegeben werden können. Nur als Idee.

[Sun1453]

@gurumeditation

Achso du meinst er bringt es an einen Pfad der für Docker / Portainer lesend zugreifbar ist. Dann könnte die APP im Docker über diesen Pfad wachen und wenn dort ein neues File da ist es nach den entsprechenden Regeln verteilen.

In dem Pfad sollte aber immer nur eine Datei und nicht alle Dateien sein, sonst ist gerade beim Hutschienen Server der Speicher schnell aufgebraucht. (Ohne Externes Medium) Oder man sagt man nimmt USB als Speicherziel und dieses ist im Portainer bemountet. Es gibt ja USB Sticks die nicht viel Platz brauchen und man steckt so einen vorn an den Hutschienen Server.

Sind erstmal mögliche Anregungen, die weiter diskutiert werden müssen.

[gurumeditation]

Genau so meinte ich das. Bin aber kein Entwickler, sondern nur Otto Normalanwender.
Daher das ganze nur als Idee, Dateien trotz Kapselung zwischen Core und Containern (Apps) auszutauschen.
Machbarkeit, Restriktionen, Regeln etc. bewerten besser "die Profis an der Quelle".

[Dante]

Ich würde es sogar noch einfacher sehen:

• Backups die der TWS erstellt speichern in der Backup-(ZIP-)Datei auch alle Metadaten (Zeitpunkt, Beschreibung, Version, etc) zur Sicherung (ggf. ist das ja bereits Stand der Dinge)
• das Verzeichnis in dem die Backups liegen, kann in beliebige Docker-Container als Volume (Readonly oder Read/Write!) eingebunden werden (ob wie das geht kann ich mangels Container/Portainer-Wissen nicht beurteilen)
• über einen HTTPS-Request o.ä. kann die Erstellung eines neuen Backups angestoßen werden, Beschreibung wird per Parameter übergeben - Alternativ kann das Backup per Logik Engine ausgelöst werden und dann kann man per Timer ein regelmäßiges Backup auslösen

Damit wären aktuell nur geringe Anpassungen notwendig und es könnten verschiedenste Backup-Lösungen auf Docker-Basis gebaut werden, die sich um regelmäßige Backups, einen Ringspeicher auf dem TWS oder der Transfer auf externe Ziele kümmern. ElabNET müsste sich keine Gedanken um den Ringspeicher machen oder über welche Protokolle das Backup irgendwo zusätzlich abgelegt werden könnte, auch das nicht zu unterschätzende Fehlerhandling kann damit entfallen.

Und Wiederherstellung läuft einfach so, dass man über den Container dann wieder die gewünschte Backup-Datei zurück in das Verzeichnis spielt und in der bestehenden Backup-Oberfläche die Wiederherstellung anschmeißt. Alternativ in der Backup-Oberfläche noch einen Upload-Button integrieren.

[Sun1453]

Hochladen eines Backups über die Oberfläche sehe ich kritisch. Timeouts sind da vorprogrammiert. Besser FTP / Sftp Upload oder direkt auf ein Speichermedium was man per USB ansteckt.

[Dante]

In Zeiten, in denen man Dateien bis 2 GB schnell per wetransfer über das Internet versendet, sehe ich den Upload innerhalb des eigenen Netzwerks als sehr unproblematisch an. Meine Backups haben aktuell ~ 180 MByte - Zuwachs mtl. ~ 8 MByte. Und bei nur 100 MBit/s wären es idealerweise keine zwei Minuten zum hochladen.

Die USB-Variante ist natürlich für ein Notfall-Recovery interessant, hier könnte der TWS ja seine Backupdateien evtl. erkennen und beim Booten direkt eine Wiederherstellung durchführen - ggf. muss die Datei sicherheitshalber entsprechend benannt werden, z.b. mit RESCUE_ davor o.ä.

[Sun1453]

Ich kenne nur diese schönen Timeouts von PHPMYADMIN und anderen Sachen, wo dann das Script stehen blieb. Maximale Scriptlauftzeit war da das Thema. Beim Rootserver konnte man diesen ja schön selbst hochschrauben, aber ohne Root Rechte ...