This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Was bringt der FSAsset für Vorteile?
#11
Also ich schreib mal provozierend ob ich die Daten als Dump aus der DB sichern muss oder direkt aus dem Filesystem. Speicherplatz brauch beides. :-) Und wenn man ein Copy-On-Write Filesystem wie Btrfs benutzt kann man Snapshots recht einfach erstellen. Beim ZFS soll es bei der Anwendung unter Linux lizenzrechtliche Probleme geben.

https://de.wikipedia.org/wiki/ZFS_(Dateisystem)
Abschnitt Weiterentwicklung:
"Eine direkte Unterstützung innerhalb des Linux-Kernels ist aus Lizenzgründen problematisch,[20] daher gibt es keine in die offiziellen Kernelquellen integrierte Linux-Implementierung.[21] "

Ok, zugegebener Maßen habe ich mit Datenbanken die GB Grössen erreichen noch nichts zu tun gehabt. Messwerte die ich bisher in einer DB gespeichert habe, brauchten nicht so viel Platz. Allerdings sehe ich einen Stolperstein wenn der DB Dump nur als eine große Datei gespeichert wird. das könnte je nach Filesystem Probleme geben. Das ließe sich aber auch umgehen, wenn man den Dump Befehl mit einem Packer über eine Pipe verknüpft. Dann könnte der Dump zum Einen gleich gepackt werden. Zum Anderen könnte der Packer die gepackten Daten auf mehrere Files verteilen. Nur ein erster Gedanke, das müsste ich auch erst noch verifizieren.

Soweit erstmal die Gedankenspiele. Aber der Punkt der Deduplizierung ist nicht wegzudiskutieren. Allerdings müßte die meiner Meinung nach ohne FSAsset dann schon in der Datenbank passieren und nicht erst im Dump. Allerdings sind Gedanken in dieser Richtung mühsig. Denn im Umkehrschluss des folgenden Zitats, gibt es anscheinend in der DB genau diese Deduplizierung nicht, sonst würde das ja in Bezug auf FSAsset nicht so betont werden.

http://opensimulator.org/wiki/FSAssets_Service:
"FSAssets is intended for grids where the size of the database is expected to exceed 50GB. This option will save the assets to the file system as opposed to the default service which stores assets as blobs in the database. This option also provides deduplication abilities, each asset is hashed when it is received for storage and if the asset already exists, the asset service will link to the existing file rather than store two copies."

!!! "... This option also provides deduplication abilities, ...."

Ausserdem sehe ich an dem Wert 50GB im Zitat, das bereits das Swissgrid, wenn man meinen letzten Post heranzieht, nicht mehr als kleines Grid zu werten ist. Also du wirst schon recht haben Bart, daß die Bedingungen unter denen FSAsset seine Stärken ausspielt schnell erreicht sind. Ok, Ihr habt mich überzeugt, ein weiterer Punkt der es wert ist, ausprobiert zu werden.
Mein Heimatgrid: https://swissgrid.opensim.ch
Zitieren
#12
Stell dir mal vor, dass deine Assetsammlung 20 GB hat. Ein Wert, den man durchaus schnell erreichen könnte - und du sicherst die Datenbank rotierend täglich, hebst dabei für jeden Wochentag eine Kopie auf. Und dabei wird ein normales Dateisystem benutzt, also ext4 oder XFS.

Der Rest deiner Datenbank liegt meinetwegen bei 2 GB. Dann hast du als Bedarf dafür 7x22 GB = 154 GB im Dateisystem. Wenn das auch noch auf einen Backupserver kopierst also täglich 22 GB Traffic.

Bei Fsasset dagegen wird einmal nur Vollbackup benötigt, danach kann man dann einfach nur noch Deltas erzeugen und die speichern. Das ist einfach viel schneller und platzsparender obendrein.

Die meisten Assets sind Bilder, und die sind mit JPEG2000 schon hoch komprimiert also bringt ein Komprimieren dieser Teile mit ZIP/Gzip/BZ2/XZ/Was auch immer kaum noch eine Platzersparnis. Also das ist mal rein von der Backupseite beleuchtet ohne COW-Dateisystem, und der Unterschied zwischen Datenbank-Dump und Bilder sind im Dateisystem gespeichert. Smile
Zitieren
#13
Stimmt! Daran, daß ein DB-Dump immer ein Vollbackup und kein inkrementales Backup ist, habe ich noch gar nicht gedacht.

Ich habe heute in einer VM testweise das Manjaro Linux noch einmal installiert. Ich konnte mich nicht mehr erinnern welche Copy-On-Write Filesystem angeboten werden. Also dabei war das Btrfs. ZFS war nicht dabei. Die Snapshots vom Btrfs haben mir schon eine Neuinstallation erspart. Es geht unheimlich schnell so einen Snapshot anzulegen und auch wiederherzustellen. Und soweit ich gelesen habe sind wohl die Snapshots automatisch inkrementell. Aber das ist für mich auch noch ein recht frisches Thema. Also immer fleißig selbst lesen. :-P

@Lukas
Das wird auch im Cinnamon unter Linux Mint unterstützt. Da gibt es ja auch  das Programm Timeshift. Das darf man nur nicht als Vollbackup sehen. Denn mit Timeshift werden die Snapshots auf der selben HD abgelegt. Aber wenn der Rechner mal nicht startet, lässt sich mit Hilfe eines Live-Image und des Timeshifts der letzte Snapshot super einfach wiederherstellen. Man muss im Timeshift nur die Partition angeben wo die Snapshots liegen. dann werden diese einem zur Wiederherstellung angeboten. Aber ein Vollbackup auf einer anderen HD muss zumindest auf der Commandozeile auch gehen. Damit muss ich mich aber auch erst noch befassen. Voraussetzung ist natürlich das die Partitionen mit Btrfs formatiert sind. 

PS:
Mit der Kombination ext4, rsync und timeshift bin ich nicht so recht zurechtgekommen. Mit dieser Kombination sah es nicht so aus, das die Snapshots wie konfiguriert automatisch angelegt werden. Mit Btrfs und timeshift habe ich bessere Erfahrungen gemacht. ... Noch kurz zur Kombination Btrfs und Timeshift. Diese Kombination funktionierte unter Linux Mint problemlos inklusive dem Aktivieren. Unter Manjaro Linux war da etwas Handarbeit notwendig.
1) $ sudo crontab -e (auch die leere Datei abspeichern, diese versucht Timeshift zu lesen)
2) $ sudo systemctl start cronie.service
3) $ sudo systemctl enable cronie.service
Mittlerweile konnte ich es testen. Der Cronie holt keine verpassten Ereignisse nach. Bei der Zeitplanung wurden keine täglichen Snapshots angelegt, denn 0:00Uhr bin ich nun mal selten online. Deshalb habe ich das Anlegen der Snapshots beim Systemstart und stündlich gewählt. Es werden jeweils immer nur 5 bzw. 6 Snapshots behalten.
Mein Heimatgrid: https://swissgrid.opensim.ch
Zitieren
#14
Darf ich noch einmal erwähnen, das ein Snapshot, der auf der Maschine gespeichert wird, auf der er erstellt wird, kein Backup ist? Tongue
Dir muss nur das Gebäude mit dem Computer abfackeln und schwupps, ist alles weg.

Es ist alles eine Frage des "Wie sehr schmerzt es mich diese Daten zu verlieren". Ich beispielsweise habe mehrere Backups in der Cloud, verteil über die ganze Welt, weil ich diese Frage für mich mit "Sehr schmerzhaft" beantworten würde. Und es gab in der Vergangenheit schon oft Fälle, wo ganze Rechenzentren abgefackelt sind.
Zitieren
#15
In der Praxis werden ganze Rechenzentren auf Grund der Wichtigkeit komplett im Ausland gespiegelt. Jedes Bit 3 mal zu speichern kann aber im privaten Bereich nicht Sinn und Zweck der Sache sein. So lange ich keine Verantwortung über 1000 Kundendaten habe, macht der Extremaufwand keinen Sinn. In diesem Fall würden natürlich auch 2 unterschiedliche Netzeinspeisungen, schnelle elekronische Umschalter und USV-Anlagen benötigt werden. Ich betrachte Client und Server als überhaupt nicht sicher und lagere meine Backups auf ein externes Laufwerk einfach aus. Dies ist auch in den Kosten akzeptabel und nachhaltig funktionell. Ich selbst würde jedem nur empfehlen Sicherungen niemals auf dem Server zu belassen. Sicherungen auf dem Server sind keine Sicherungen. Clients und Server spielen für mich keine wichtige Rolle, weil eine Neuinstallation keine Extremzeit benötigt. Ich bin lieber sicher, dass ich kein verseuchtes System-Backup einspiele. Firmen und Unternehmen haben ganz andere Vorgehensweisen, Richtlinien, Personal und finanzielle Mittel die privat nicht greifen. Im Bezug auf OpenSim sichere ich nur die von mir serstellten .iar und .oar. Der Rest ist für mich persönlich nicht relevant.
All done!
Zitieren
#16
(15.04.2022, 10:29)Lukas schrieb: [...] So lange ich keine Verantwortung über 1000 Kundendaten habe, macht der Extremaufwand keinen Sinn. [...]

Das ist, wie gesagt, immer eine persöhnliche Sache und dem persöhnlichen Wert der Dateien geschuldet.
Ich beispielsweise bezahle regelmäßig Künstler mir Bilder zu zeichnen. Da gehen für ein Bild auch mal 300€ über den Tisch. Diese Bilder existieren rein digital. Daher sichere ich meine Daten (inkl. dieser Bilder) so häufig und massiv ab. Da stecken richtige Werte drin Smile
Die Musik- oder Filmsammlung muss man natürlich nicht so krass sichern, an diese Daten kommt man immer irgendwie wieder ran.
Zitieren
#17
Ja, jetzt verstehe ich das besser.

Interssant ist allerdings die Frage, wie es zu einem Brand in einem Rechenzentrum überhaupt kommen kann.

Normalerweise sind ja immer Sicherheitskonzepte für den sicheren Betrieb erarbeitet. Regelmäßige Überprüfungen vom TÜV, Feuerwehr

und Wartungen an Elekrotechnischen Anlagen, USV, BSK, Lüftung etc. einschließlich der Kälteversorgung sollen ja zur Sicherheit beitragen.

Prüfprotokolle mit Prüffristen füllen ganze Ordner und Schränke und beschäftigen ganze Teams.

Würde man (nur mal als Beispiel) feststellen, dass der Rauchmelder mit der Nr: 18/3 nicht ausgelöst hat,

dann folgen Arschkarten - Kein schönes Spiel.

Da wird man sicher den Betreiber der Anlagen und den qualifizierten Fachkräften einige Fragen stellen.
All done!
Zitieren
#18
Also bei OVH in Straßburg damals war es vermutlich die USV, die den Brand verursachte. Ein Tag vorher gab es dort Wartungsarbeiten, und dabei ging wohl irgendwas schief. Dazu wird vermutet, dass der Brand auch recht spät von den Detektoren entdeckt wurde. Das Hauptproblem war dann, dass es in der Anlage keine aktiven Löschsysteme gab, also keine Sprinkleranlage, CO2 o.ä.

Daher fackelte das Teil dann einfach ab.

https://winfuture.de/news,121694.html

Grundsätzlich kann in einem Rechenzentrum viel brennen. Die Klassiker sind für mich ein Kabelbrand, wenn zu viel an einer Leitung hängt. Oder ein zu warm werdender Elko, der dann letztendlich kocht und platzt, dabei sein Dielektrikum auf einer Platine verteilt. Da das elektrisch leitend ist, kann das dann schlimmstenfalls zu einem Platinenbrand kommen.
Zitieren
#19
(15.04.2022, 06:51)Kubwa schrieb: Darf ich noch einmal erwähnen, das ein Snapshot, der auf der Maschine gespeichert wird, auf der er erstellt wird, kein Backup ist?....
 
Das ist völlig korrekt, aber darauf hatte ich auch hingewiesen.
"... Das darf man nur nicht als Vollbackup sehen. ... Aber ein Vollbackup auf einer anderen HD muss zumindest auf der Commandozeile auch gehen. ..."

Wobei Vollbackup nicht gut formuliert ist, es kann ja auch inkrementell gesichert werden. Ersetzt das bitte gedanklich einfach durch Backup.

Diese Snapshots dienen mir lediglich dazu, das System einen Schritt zurücksetzen zu können, falls man etwas total verkonfiguriert hat oder ein Update schief geht. Sie sind also mit den Wiederherstellungspunkten unter Windows vergleichbar. Meine eigentlichen Backups von meinem Arbeitsrechner liegen auf einem NAS und online auf einem Server. Da ich bei NightRaven im Swissgrid untergeschlüpft bin, brauche ich ja keinen eigenen Opensim-Server.
Mein Heimatgrid: https://swissgrid.opensim.ch
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste