Welcher Opensim Modus taugt für wen?

[Tron Mcp]

Gridmodis in Opensim 
- Hilfe bei der Auswahl der nach Anwendungsfall am besten geeigneten.


Opensim ist eine sehr flexible Konstruktion für unterschiedliche Bedürfnisse. 
Diese unterschieden sich hinsichtlich Installationsaufwand, Flexibilität, Hardwarebedarf, Kosten, Ausbaufähigkeit und natürlich der geplanten Nutzung.

Was für den Profi Flexibilität bietet macht aber den Anfänger das Leben schwer.

Daher eine kurze Einführung in die Gridmodis von Opensim bezüglich der Auswahl und Konfiguration.
Ausdrücklich lasse ich alle anderen Wahlmöglichkeiten weg.

Folgende Betriebsmodi kennt Opensim:


1. Standalone :

Eine mini Testinstallation auf einem Rechner mit einer Instanz (ohne eigene Robust) und maximal ca. 4 Sims, ohne Hypergrid Anschluß.

Anwendungsfall: Ein Testrechner daheim ohne Internetzugang. Ein Mesh Entwicklungs Rechner um Uploadkosten in Sl zu sparen.

Performance: schlecht da nicht skalierbar. Alle Dienste (Griddienste, und alle Sims) laufen in einer einzigen gemeinsamen Instanz. 
Für das gesamte Opensim Set kann aber nur genau ein Core einer CPU verwendet werden!!!!

Benutzte Konfig Dateien 
(im Ordner config-include) : Standalone.ini und Standalone.common.ini
( im Ordner bin): Opensim.ini

Bewertung: Den standalone Gridmodus nutze man wirklich nur für lokale private Sandboxen und kleine Entwicklungs/Test Umgebungen.
Er macht nur Sinn wenn man auf eine "richtige" Datenbank verzichtet um einfache Backups durch kopieren der gesamten Ordnerstruktur durchzuführen.
Dann bleibt dieser Ordner auch super portabel. Man kann so die gesamte Installation auf USB Medium zwischen Rechnern und Standorten bewegt werden oder Snapshots durch kopieren anlegen.

Typisch sind da 1-2 Avatare und maximal bis zu 4 Sims. Darüber leidet die Performance massive da für alles zusammen nur 1 Core verwendet wird.
Dafür benötigt diese einfache Umgebung keinen eigenen Rechner. Es reicht eine VM oder die Ausführung am gleichen Rechner der den Viewer startet.


Nachteil: Nicht Wachstumsfähig, geringe Performance die ab 2 Sims einbricht, kein Hypergird Material. Administration selbst zu erbringen. Nicht geeignet für mehrere Nutzer.
Vorteil: Unabhängigkeit, gesicherte Testumgebung ohne äußere Einflüsse, leichte Backup, wenig Konfiguration, keine SQL Datenbank.

-------------------------------------


2. Standalone Hypergrid:  (wie Standalone, jedoch nun mit Hypergrid Anschluß).

Anwendungsfall: Typisch ein Rechner daheim am privaten DSL Anschluß. 
Man hat bis ca 4 Sim, wenig Performance da nur 1 Core verwendet wird, kann aber im Hypergrid rumspringen.

Performance: schlecht da nicht skalierbar. Alle Dienste (Griddienste, und alle Sims) laufen in einer einzigen gemeinsamen Instanz. 
Für das gesamte Opensim Set kann wieder nur genau ein Core einer CPU verwendet werden!!!!

Benutzte Konfig Dateien
(im Ordner config-include) : StandaloneHypergrid.ini und Standalone.common.ini
( im Ordner bin): Opensim.ini

Bewertung: Dieses System ist typisch für eine private 1-Personen Opensim Umgebung die nicht ständig am Netz ist, und nur bei Bedarf gestartet wird,
Das ist sicher die einfachste (Konfiguration) und billigste Möglichkeit (Internet, variable IP, keine Domäne, Rechner, Strom) um am Opensim Geschehen teilzunehmen und ein bissl selber zu bauen.

Typisch ist dafür ein eigener zusätzlicher (alter) Rechner zuhause der bei Bedarf gestartet wird. Es kann aber auch eine Mitnutzung eines performanteren Systems sein auf dem der Viewer läuft.

Nachteil: Nicht Wachstumsfähig, geringe Performance die ab 2 Sims einbricht. Administration selbst zu erbringen. Wenig geeignet für mehrere Nutzer.

Vorteil: Unabhängigkeit, leichte Backup, mittlere Konfiguration, keine SQL Datenbank, daheim betreibbar, geringe Kosten.


-------------------------------------



3. Grid: Ein mittleres bis großes abgeschottetes Grid ohne Hypergrid Zugang.

Anwendungsfall: Ein abgeschlossenes Grid wie SL mit eigenen Benutzern und eigenem Kontent. Es ist keine Interaktion mit anderen Grids möglich.
Eine Anwendung im Schulungscenter, Schule etc ist denkbar, wo die User von externen Einflüssen im Internet abgeschirmt werden sollen.

Performance: sehr gut skalierbare Performance, da (mindestens) eine separate Robust Instanz für Griddienste verwendet wird, 
und je Sim einen eigene Instanz möglich ist. Ausserdem kommt die viel performantere MYSQL Datenbank zum Einsatz.
So wird die Last über mehrere Cores verteilt, und bei Bedarf sogar über mehrere Server skaliert.

Benutzte Konfig Dateien ist unterschiedlich ob Robust Instanz oder SIM Instanz:
( im Ordner config-include) : Grid.ini und Grid.common.ini
( in SIM Instanzen im Ordner bin): Opensim.ini
( in Robust Instanz im Ordner bin): robust.ini

Bewertung: Wer viele User oder viele Sims hat, aber nicht mit anderen in Kontakt kommen will wird in diesem Gridmodell glücklich.
Die Performance ist beliebig skalierbar. Das Grid kann sich über eine oder mehrer Datenbanken erstrecken. Ausserdem können mehrer Server die Sims hosten.
Dafür wird aber unbedingt eine vollwertige Datenbank wie MYSQL benötigt. Auch eine Feste IP ist Pflicht. Sim Instanzen und Robust Instanz kommunizieren über IP.
Typisch ist dafür die Anmietung mindestens eines Servers im Rechenzentrum, oder hosting im eigenen Unternehmen / Schulungsbetrieb, etc.

Nachteil: beschränkte Attraktivität. Useranzahl und Materialauswahl ist viel geringer als im Gridverbund. Hohe Verantwortung, hoher Pflegeaufwand für Backups, Datenbank Pflege, IT Sicherheit, Verwaltung. ggf. Kosten für Internetanbindung, Servermiete, Administration.
Hoher Aufwand bei Gridumstellung und Hardwareumzug durch MYSQL Datenbank(en).

Vorteil: skalierbare gute Performance, fremd gemanagtes System für unbedarfte User


-------------------------------------



4. Grid Hypergrid: Ein mittleres bis großes Grid mit Hypergrid Zugang. 
Dieses ist die gebräuchlichste, scalierbarste und damit zukunftsfähigste Gridform in Opensim.

Anwendungsfall: Technisch ähnlich wie Gridmodus, jedoch dürfen User (frei) mit anderen Grids interagieren.
Material und Nachrichten können ausgetauscht werden.

Und es ist möglich fremde Sim Instanzen an das eigene Grid anzubinden. 
Letzteres ist ein Sonderfall, wo alle Avatar Dienste zentral bereit gestellt weden, jedoch die Siminstanzen dezentral auf eigenen Resourcen betrieben werden.
Beispiel ist OSGrid wo man eigene Sims "andocken" kann.

Performance: Wie Gridmodus, super und breit skalierbar. Das Grid kann bei Wachstum beliegig erweitert werden.

Benutzte Konfig Dateien:
( im Ordner config-include) : Hypergrid.ini und Grid.common.ini
( in SIM Instanzen im Ordner bin): Opensim.ini
( in Robust Instanz im Ordner bin): robust.hg.ini

Bewertung: Flexibelste wachstumsfähige Installation. Aber die Verantwortung des Administrators wächst mit der Userzahl.
Es braucht einen Profi der sich um Datensicherheit, Datenbankpflege, Konfiguraton, Backups, Userprobleme und nicht zu vergessen IT Sicherheit kümmert.
Fehler im System treffen viele und sind schmerzlich. Beispiel halbjähriger OSG Ausfall wegen Datenverlust bei RAID Problem.

Nachteil: hohe Verantwortung, hoher Pflegeaufwand für Backups, Datenbank Pflege, IT Sicherheit, Verwaltung. Kosten für Internetanbindung, Servermiete, Administration. Hoher Aufwand bei Gridumstellung und Hardwareumzug durch MYSQL Datenban(en).

Vorteil: skalierbare hohe Performance, fremd gemanagtes System für unbedarfte User, maximale User Flexibilität.

-------------------------------------


5. und 6. Simian und SimianHypergrid: Proprietäres Grid, wird nicht mehr unterstützt seit Version 0.9.2


-------------------------------------



KONFIGURATION:

Wenn man sich für das geeignete Grid entschieden hat, gilt es diese Auswahl dem Simulator in der Konfiguration mitzuteilen.

Dazu muss man wissen das diese Gesamtkonfiguration (um es den Admins zu erleichtern) in etliche verschiedenen Dateien verteilt wurde.
Diese orientieren sich grob an dem Gridmodus (mit/ohne separater Robust Instanz, mit/ohne Hypergrid Unterstützung)
Es könnten aber auch alle gewählten Einstellungen in eine Datei kopiert werden.

Diese einzelnen Konfig (.ini) Dateien werden in einer festgelegen (aber beeinflussbaren) Reihenfolge aufgerufen.
Dabei werden jeweils Variablen definiert und mit Werten belegt.

Duch den Aufruf nacheinander ist es vorgesehen das ein und dieselbe Variable an verschiedenen Stellen unterschiedliche Werte zugewiesen bekommt, und die zuletzt aufgerufenen Stelle vorhergehende Werte überschreibt.

Grob gesagt geschieht dies folgendermaßen in jeder Instanz (mit Ausnahme der Robust Instanz!):

Zuerst wird im bin Verzeichnis die "default" Datei aufgerufen (OpenSimDefaults.ini) und die Werte belegt.
Danach die Spezifikations .ini Datei  (Opensim.ini) in der ihr unpassende default Werte durch eure gewünschte eigene Konfiguration überschreibt.

In dieser Opensim.ini gibt es einen Aufruf zu den ausgelagerten Grid Modi Konfigurations Dateien.

Diese befinden sich in der Opensim.ini unter:

[Architecture]
Include-Architecture = "Wert"

Wobei Wert je nach dem oben gewählten Gridmode auf das Verzeichnis und die zugehörige Config Datei hinweist:

1.  Include-Architecture = "config-include/Standalone.ini"
2.  Include-Architecture = "config-include/StandaloneHypergrid.ini"
3.  Include-Architecture = "config-include/Grid.ini"
4.  Include-Architecture = "config-include/GridHypergrid.ini"

An dieser Stelle könnt ihr ablesen in welchem Modus euer Simulator läuft!


Also überschreibt diese jeweilige Datei bereits vorhandene Einträge der Variablen aus den vorhergenannten 2 Dateien

Die Dateien je Modus, habe ich ja oben in der Modi Beschreibung schon angegeben.
Wir sehen also das die 3. aufgerufenen Konfig Datei die "spezielle" pro Gridmodus ist.
Am Anfang dieser Dateien befindet sich dann jeweils wieder ein Aufruf auf ihre zugehörige "Common" Datei.

Es gibt davon aber nur 2 Unterschiedliche:

1.) und 2.) nutzen die StandaloneCommon.ini
3.) und 4.) nutzen die GridCommon.ini
da in den Dateien Standalone.ini,  StandaloneHypergrid.ini, Grid.ini, GridHypergrid.ini der Aufruf der Common Datei am Anfang steht wird wohl diese Common jeweils zuerst ausgeführt.

Dies Konstrukt gibt es pro "Nicht Robust" Instanz". Die Dateien unterschiedlicher Instanzen sollten sich nicht widersprechen.
In meinem Grid sind sie bis auf die Portnummern und die Region Dateien identisch gehalten, was die Pfelge erleichtert.

Nun das Konstrukt ist flexibel ,aber hochgradig verwirrend. 
Man braucht sich nicht zu wundern wenn gesetzte Parameter dann wieder überschrieben werden.

Ausserdem verwirren unbenötigte brachliegende Dateien zusätzlich.
Daher mein Tip: Beim Aufsetzten des Grids vorab überlegen welchen Gridmodus man will, 
und von den in diesem Artikel genannten, nicht benötigte inis, und .default Vorlagen löschen was nicht benötigt wird.
Ausserdem macht euch eine externe Doku welche Optionen wie konfiguriert sind, dies braucht ihr spätestens beim nächsten Opensim Versionsupdate.

Dies gilt für alle "Nicht Robust" Instanzen.


ROBUST INSTANZ :

In der Robust Instanz wird die Robust.ini oder die Robust.HG.ini verwendet (je ob ohne oder mit Hypergrid)
Diese schaut nach weiteren nachzuladenden Konfig Dateien in das Verzeichnis "robust-include"

ConfigDirectory = "robut-include"

Ich habe keinen Aufruf in der robust Instanz auf weiterere (Gridmodus-) Config Dateien gefunden.

Somit ist insbesondere egal was in der Opensim.ini der Robust Instanz drin steht.


So- das wars im Groben.

Es ist verwirrend, und erfordert große Ordnung


Aber es ist kein Hexenwerk wenn man die Zusammenhänge kennt.

[ThunderTower]

Das ist absolut richtig!
Eine sehr wertvolle beeindruckende Dokumentation, weil sich mit ihrer Hilfe schon sehr gute Überlegungen zur Planung anstellen lassen. Ein wichtiges Fundament also, um auch nachhaltig Freude am Server zu haben. Es ist einfach toll zu lesen, mit welcher umfangreichen Arbeit unsere Autoren Ihre Fachbeiträge publizieren. So bietet es jedem Leser die Möglichkeit, sich selbst fachlich korrekt weiterzubilden. Diese verschiedenen OpenSim-Betriebsmodi sind nur für Serverbetreiber interessant. Nicht relevant für Benutzer.
Danke Tron

[ThunderTower]

Es kann auch eine SQL-Datenbank in der Standalone verwendet werden.

Dabei geht es nur darum, Kenntnisse zur Migration mit MySQL weiter zu vertiefen.

Nicht selten hat man beim Wechsel von SQLite auf MySQL Schwierigkeiten.

Der entsprechende Eintrag erfolgt in der StandaloneCommon.ini ganz oben.

Bei dieser Migration kommen neue Abfragen zu Estate, Benutzer und Passwort.

Pfad: StandaloneCommon.ini

~/opensim/opensim-0.9.2.0/bin/config-include/StandaloneCommon.ini

   

[Tron Mcp]

Ja, natürlich kann in jedem Modus eine MYSQL Datenbank verwendet werden, da die Konfiguration davon unabhäbgig ist.

Es gab auch früher eine SimOnaStick Distribution die genau dieses machte. Das war eine Standalone Hypergrid mit MYSQL portabel und 4 Sims. Dennoch war die Leistung schnell im Anschlag, da alle 4 Sims und die Zentralen GridDienste in einer Instanz liefen, und der Rechner hat sich langweilt.

Bei einer "üblichen" MySQL Installation verliert die Installation ihre Portabilität, und somit ihr leichtes Backup sowie die Möglichkeit Snapshots zur Versionierung zu verwenden.

Es kommt also darauf an was man testen will:

Will man nur einzelne Sims, Backups oder Mesh Upload testen ist die portable Verision mit der SQLight besser geeignet.

Testet man dagegen Funktionalität von Simulator Versionen, braucht man die MYSQL, da nur diese alle Funktionen bereitstellt.
Beispielsweise wurden Gruppen und offline IMs mit Sqlight früher nicht unterstützt. (Aktuelle Version hab ich diesbezüglich nicht getestet)

Macht man sich aber den Aufwand einer MySQL Installation, so ist auf jeden Falle die Grid (Hypergrid) Version die bessere, das sie erweiterbar ist.

Frage an dich Lukas: Kennst du eine praktikable Möglichkeit der Datenmigration von SqLight auf MYSQL mittels Script?
Wenn ja dann beschreibe die bitte genau in einem Artikel, denn das würde all jenen helfen die im falschen Gridmodus gestartet sind, und nun nicht erweitern können.

Ich hab in diesem Falle bisher mit IAR und OAR Export/Import gearbeitet, was fehlerfafte Assets aussortiert.
Nachteil ist das etliche Usereinstellungen dabei verschwinden- wie zusammengestellte Outfits.

[ThunderTower]

Damit habe ich mich noch nicht beschäftigt. Ob Scrips diese besprochene Migration von SQLite zu MySQL fehlerfrei meistern? Lite-Datenbanken (also .db) von einer SQLite zu sichern und selbigen SQLite-Dump dann auch noch in die MySQL-Datenbank zu importieren, würde ich nur mit spezieller für die Migration ausgelegter fertiger Software machen.

Weitere Hinweise siehe PN

[Tron Mcp]

Nun in beiden Datenbanken liegen die Opensim Daten in Tabellenform in jeweils mehrerne Tabellen vor.

Welche dieser einzelnen Tabellen angelegt werden hängt unter anderem an der Opensim Version und (eventuell) an den gewählten Features.
Manche Tabellen verbleiben aber auch einfach leer wenn entsprechende Features deaktiviert sind.

Vor einer Portierung müsste die Tabellenstruktur auf Gleichheit geprüft werden, was auf jeden fall Opensim Versions Abhängig ist.
Opensim führt Pro Tabelle eine Versionsnummer der Struktur. Upgrade von alt auf neu wird automatisch unterstützt.

Die Gleichheit der Tabellenstruktur ist daher wichtigstes Kriterium das es vorab zu checken gilt.

Ausserdem ist bekannt das in der "kleinen" SQLite eine Untermenge der Tabellen der "Großen" MYSQL Variante angelegt werden.
(Einige Features werde daher nicht mit der Kleinen Datenbank unterstützt.)

Die Migration pro Tabelle wäre dann 2-Stufig machbar:

1. Export in eine Datei mit gewählten Trennzeichen zwischen Datenspalten.
2. Import in die neue Struktur unter Beachtung der gewählten Trennzeichen.
mit SQL Befehlen ist das machbar.

In Oracle DBs hab ich das selber schon gemacht, aber es lohnt sich halt nur wenn es weniger Aufwand macht als die IAR/OAR Vorgehensweise.
Und das dürfte erst bei sehr goßen Grids gegeben sein.

[ThunderTower]

Im /bin [Hauptverzeichnis] befindet sich:

OpenSim.db
Asset.db
auth.db
avatars.db
friends.db
userprofiles.db
griduser.db
inventory.db

Der Pfad zur SQLiteStandalone.ini:

~/openzims/opensim-0.9.2.0/bin/config-include/storage$ nano SQLiteStandalone.ini

Mit folgendem Inhalt:

; These are the initialization settings for running OpenSim Standalone with an SQLite database

[DatabaseService]
StorageProvider = "OpenSim.Data.SQLite.dll"
ConnectionString = "URI=file:OpenSim.db,version=3,UseUTF16Encoding=True"

[AssetService]
ConnectionString = "URI=file:Asset.db,version=3"

; The HGAssetService section controls the connection given to the AssetService in a Hypergrid configuration.
; This has to be separate from [AssetService] because the Hypergrid facing connector uses [HGAssetService] for its config data ins>
; However, the internal asset service will still use the [AssetService] section.
; Therefore, you will almost certainly want the ConnectionString in [HGAssetService] to be the same as in [AssetService]
; so that they both access the same database.
; This issue does not apply to normal MySQL/MSSQL configurations, since by default they use the settings in [DatabaseService] and
; do not have separate connection strings for different services.
[HGAssetService]
ConnectionString = "URI=file:Asset.db,version=3"

[InventoryService]
;ConnectionString = "URI=file:inventory.db,version=3"
; if you have a legacy inventory store use the connection string below
ConnectionString = "URI=file:inventory.db,version=3,UseUTF16Encoding=True"

[AvatarService]
ConnectionString = "URI=file:avatars.db,version=3"

[AuthenticationService]
ConnectionString = "URI=file:auth.db,version=3"

[UserAccountService]
ConnectionString = "URI=file:userprofiles.db,version=3"

[GridUserService]
ConnectionString = "URI=file:griduser.db,version=3"


Ich lese da etwas von einem UTF16 Datenbankformat bei der SQLite. !?

[ThunderTower]

Zu Punkt 4. Grid Hypergrid: (Ein mittleres bis großes Grid mit Hypergrid Zugang) habe ich eine kleine Zeichnung gemacht.

Dies entspricht unserer realen Konfiguration. Natürlich ist meine Zeichnung nur eine grobe Übersicht. Diese Art der Konfiguration finde ich sehr flexibel.

Teilbereiche lassen sich nach Bedarf hoch und auch runterfahren.

Diese Möglichkeit ist z.B bei Veranstaltungen sehr wichtig.

Ein Datenbankwechsel auf mysql sollte gleich nach der ersten automatischen Initialisierung von SQLite erfolgen. Selbst wenn die eingegeben Daten in die SQLite umsonst sind.

   

Normalfall:

Die Einstellung zur Datenbank macht man vor dem ersten Gridstart, da sonst bereits Teile der Daten verloren gehen.

Typischerweise richtet man zuerst die Datenbank ein, dann installiert man die Robust.

Wenn die läuft konfiguriert man die erste Siminstanz mit der Datenbank.

Im Normalfall nimmt man nur eine einzige Datenbank, die gemeinsam von Robust und allen Sims genutzt wird.

Erst wenn man diverse Fremdserver im Grid andocken läßt, so legt man die Fremdsims auf deren eigene Datenbank.

Der Hintergrund ist kurze Latenz zwischen Sim und SIM Datenbank, sowie Vertrauen.

Wird das Grid mittelgroß dann macht man einen eigenen Server für die zentrale Datenbank.

Nur bei einem sehr großen Grid wie Opensim reicht dann eine Datenbank nicht mehr.

Dann spittet man sogar Dienste auf- für jeden Dienst einen Datenbank.

Wichtig ist so wenig Angriffsprofil im Internet zu beiten wie möglich.

Daher besser dicken Server und keine Sim/Robust -> Datenbank Zugriffe über externes Netz.

Die Fallunterscheidung ist ja nach Gridgröße unterschiedlich.

Skizze mit nur einer Datenbank für den Normalfall:

   

[Bartholomew Gallacher]

Ich halte die Kriterien, nach denen hier die Performance der diversen Anwendungsfälle bewertet wird, für etwas irreführend und nicht ganz zielführend.

Der Grund ist einfach der, dass die Performance-Bewertung hauptsächlich vom gewählten Einsatzzweck der Installation abhängen sollte.

Wenn beispielsweise mein Einsatzzweck für meine Sim einfach nur kleines Wohnzimmer im weiten Internet sein sollte, dann ist die Performance von Standalone nicht wesentlich schlechter als Grid oder Grid/Hypergrid solange ich wohl nicht auf die Idee komme, dort 100 Avatare gleichzeitig haben zu wollen.

Es ist natürlich richtig, dass mit Robust und MySQL das System grundsätzlich deutlich besser skalieren kann. Auch weil man es dann auf mehrere Server verteilen kann.

Aber auf den Einsatzzweck kommt es an - wer nur sein eigenes, kleines Wohnzimmer haben will und 2-3 Avatare zu Besuch, für den macht Standalone Hypergrid mit MySQL absolut keinen Unterschied in der Performanz zu Grid Hypergrid. Grundsätzlich würde ich Opensim immer von Anfang an nur mit MySQL benutzen.

Ich denke daher, dass für 90% der Benutzer Standalone oder Standalone Hypergrid eine mehr als ausreichende Leistung abliefern, da die meisten eben genau das haben wollen: ein eigenes, kleines Wohnzimmer im Metaversum, wo sie ab und an von paar Freunden besucht werden können.

Einen gewaltigen Unterschied allerdings macht es dann in der Konfiguration, weil man für Robust eben mehr Teile konfigurieren muss als für Standalone Hypergrid alleine. Man kann es natürlich machen, aber es dürfte von der Installtion her komplexer sein und was komplexer ist, hat auch mehr Fehlerquellen.

Zum Thema Sqlite nach MySQL: die beste Herangehensweise wird sein, immer mit MySQL anzufangen. Sqlite hat für mich nur genau einen sinnvollen Einsatzzweck: Sim on a Stick. Es gibt gewisse Unterschiede zwischen Sqlite und MySQL, so dass eine Konvertierung nicht ganz einfach zu erledigen ist, sofern man nicht bereits existierende Skripte nutzt. Und wenn es Skripte gibt ist die Frage, ob die noch aktuell genug sind für die aktuelle Opensim-Version.

Genau deswegen empfehlen die meisten Anleitungen für solche Konvertierungen dann IARs und OARs zu nutzen. Allerdings gehen auf diesem Weg natürlich gewisse Infos, wie z.B. Gruppen, verloren.

[Tron Mcp]

Die SimonaStick mit der ich angefangen habe, hatte witzigerweise sogar eine MYSQL. Da haben sie beachtliche Tricks hingelegt um diese MYSQL portabel zu machen.

Für den nomalen User ist dies nicht zu erreichen.
Für den gilt grob:

SQLITE = Portabel
MYSQL = Nicht Portabel.

Und Portabilität bedeutet auch einfaches Backup ohne sich gut auszukennen zu müssen.
Einfach Simlator herunterfahren, dann die gesamte Ordnerstruktur auf ein anderes Backupmedium kopieren - fertig.

Und genauso einfach ist die Wiederherstellung:

- Defekte Originalstruktur ggf löschen, dann das Backup in die selbe Laufwerk/Ordnerstruktur zurückkopieren und starten - fertig.

Nicht einmal die Firewall muss danach aktualisiert werden.