Wichtige Hinweise zur BlobDB-Speicherung in b1gMail 7.4

patrick

patrick

Staff member
B1G-Software-Kunde
Hallo,

wir möchten hiermit auf zwei Dinge im Zusammenhang mit der Speicherung von E-Mails in BlobDBs ("eine Datei pro Benutzer") hinweisen:
  • Einige wenige Shared-Webhoster beschränken die Größe pro Datei auf dem Webspace. (Beobachtet z.B. bei Strato mit einem Limit von 1 GB.) Dies kann bei Verwendung der BlobDBs negative Auswirkungen haben: Überschreitet die Größe der Mailbox des Benutzers das vom Hoster gesetzte Limit, können keine neuen Mails mehr in der BlobDB gespeichert werden und man riskiert Datenverlust! Je nach Implementierung auf Hoster-Seite wird die Datenbank hart an der Limitgrenze abgeschnitten und kann dadurch auch in ihrer Struktur beschädigt werden! Daher empfehlen wir, bei Providern, die ein solches Limit realisieren, dringend auf die herkömmliche Speichermethode ("eine Datei pro Objekt") für E-Mail und Webdisk zurückzugreifen.

  • Wenn der b1gMail-data-Ordner auf einem NAS gespeichert wird, ist es im Allgemeinen stabiler und sicherer, die herkömmliche Methode ("eine Datei pro Objekt") zu verwenden. Viele Netzwerkdateisystem haben Probleme mit dem von SQLite (das ist die Storage-Engine für die BlobDBs) genutzten File-Locking. Bei SQLite rät man daher generell davon ab, auf NAS zu speichern. Man riskiert hier vor allem, dass eine BlobDB unberechtigt gelockt bleibt und der User dann keine Mails mehr empfangen und lesen kann, bis man die Verbindung zum NAS neu aufbaut oder den Prozess, der den Lock hielt, beendet (je nach Problem in der Locking-Implementierung).
Wir empfehlen daher generell, die Speicherung "eine Datei pro User" nur zu verwenden, wenn man einen eigenen Server hat und die Daten auf einer lokalen Festplatte ablegt.
 
Ich denke, b1gMail sollte in dem Fall warnen oder die Funktion deaktivieren, wenn ein Shared Hoster vermutet wird oder die Dateigröße zu gering ist. Das ist schließlich relativ gefährlich so.
 
central said:
Ich denke, b1gMail sollte in dem Fall warnen oder die Funktion deaktivieren, wenn ein Shared Hoster vermutet wird oder die Dateigröße zu gering ist. Das ist schließlich relativ gefährlich so.
Click to expand...
Es gibt leider kaum eine Möglichkeit, dies codebasiert herauszufinden. Ein entsprecher Hinweis im ACP wird aber nachgerüstet.

Unabhängig davon halte ich das persönlich für ein Riesenproblem beim Webhoster, wenn der einfach so Kundendaten verwirft...
 
Der Nutzer der B1gmail erwirbt und nutzen möchte, sollte sich auch einen Server beschaffen und einen großen Bogen um Webhoster machen da man eh eingeschränkt ist.
 
Oder BlobDBs nur erlauben wen der b1gMailServer vorhanden ist da man dann annehmen könnte das ein eigener Server in betrieb ist.
 
Das ist tatsächlich schwer, mittels Code herauszufinden. Was keine schöne Lösung, aber vielleicht ein möglicher Ansatz wäre: ein Script, das versucht, eine sehr große Datei zu schreiben. Im ACP könnte man eine Funktion zum "BlobDB-Test" anbieten, die nach und nach eine immer größere Datei schreibt. Der Benutzer könnte hier ja auch ein Limit angeben, z.B. "teste bis 4 GB". Da muss man nur aufpassen, dass das Auslesen der Dateigröße unter 32bit-Systemen zu Problemen führen kann (in diesem Fall könnte man auch eine Warnung anzeigen). Auch weiß ich nicht, wie Windows mit solchen Dingen umgeht.

BlobDBs bei Installationen, die keinen b1gmailServer nuzen, generell zu verbieten, könnte zwar auch eine Lösung sein. Allerdings sollte es auch hier noch die Möglichkeit geben, mittels einer "ich bin mir wirklich sicher"-Funktion auch auf anderen Installationen die BlobDBs zu aktivieren - ich selbst nutze den b1gmailServer nicht, habe aber einen eigenen (managed) Server, bei dem ich die neue Speichermethode sehr gerne nutzen würde.
 
Manche b1gMail-Installationen (wie auch unsere) lagern die Daten auf externe Storages aus. Um unter dieser Konstellation auch z.B die Geschwindigkeistvorteile der BLOB-Variante nutzen zu können wäre es wichtig, eine intelligente Speichermethode zu finden, die auch bei großen Datenmengen verwendet werden kann.

Accounts können aus unserer Erfahrung heraus die 1GB-Marke und mehr locker erreichen. Evtl liese sich ein Speichersystem implementieren, dass nach Monat und Jahr ablegt. Und wenn das Speichervolumen pro Datei erreicht wird, wird das Volumen in einer 2. oder 3. Datei weitergeführt (nur so als Laie gedacht).

Aber eben nicht mehr in tausenden von kleinen Files, der größte Nachteil der aktuellen Dateispeichermethode.
 
Welchen Vorteil hätte ein Zerstückeln der Mailbox gegenüber einer großen Blob-Datei? Also die Lösung mit einer Datei pro Benutzer scheint doch gerade das zu sein, was bei vielen Benutzern die besten Eigenschaften hat, oder übersehe ich da was?
 
Nein habe auch schon beim ersten präsentieren der neuen Speicherart meine bedenken, denn so wird jedesmal ein komplettes Backup angelegt.

Aus meiner Sicht wäre viel besser die Option zu haben das pro Jahr oder Monat eine neue Datei angelegt wird denn aus Erfahrung wird nichts gelöscht daher ändern sich nur die "aktive" Datei (Jahr oder Monat) und man kann inkrementelle Backups erstellen. Das Daten Volumen / Backup Zeit wird so einiges kleiner...
 
Um bei backups (platz) sowie Zeit zu sparen sollte man schauen das man snapshots erstellt ;)

Platz Spart man nicht wirklich, aber der vorteil vorallem bei blobdb‘s ist hier gegeben da nicht jedes mal ein vollbackup gezogen werden muss.

Mal so an @patrick du sagst NFS sollte man nicht verwenden wie sieht es denn z.B. Mit iSCSI aus in verwendung mit blobdb‘s?

Vollbackups/Inkrementelle Backups haben auch hier und da nachteile...
 
Mal so an @patrick du sagst NFS sollte man nicht verwenden wie sieht es denn z.B. Mit iSCSI aus in verwendung mit blobdb‘s?
Click to expand...
Sollte (!) kein Problem sein, da iSCSI ein Block-Device exportiert , also eine Schicht unter dem Dateisystem liegt, und das Locking usw. dann wie bei einer lokalen Festplatte realisiert wird.

Bzgl. Backups ist die schnellste und einfachste Möglichkeit m.E. derzeit auch ein Snapshot. Dateiweise zu sichern ist meist langsam und wenig praktikabel... Bei Hetzner Cloud kann man z.B. für ein paar Prozent Aufpreis per Klick eine Backupfunktion aktivieren, die nächtlich ein Snapshot des gesamten (Cloud-)Servers sichert, ohne bemerkbaren Einfluss auf den Server selbst.
 
Das Problem ist immer bei den "Snapshot" Funktionen das bei 90% der Anbieter nur ein Snapshot erstellt wird der aber nicht weggesichert wird.
Den das ist kein Backup sondern nur bei Wartungsarbeiten als Sicherheit anzuschauen...

Finde die BlobDB Sache wirklich gut aber man müsste wirklich einen weg finden das nicht jedesmal bei x GB an Files nicht jedesmal eine komplett Sicherung gemacht werden muss den das braucht definitiv zu viel Backup Platz wen man die Backups 30 Tage oder mehr aufbewahrt, dann ist mir die "alte" art lieber da läuft das Backup zwar einiges länger muss aber nicht jedes Mail x mahl vorhanden sein.
 
Finde schon das snapshots eine gute „backup“ lösung sind... man sollte halt aber auch die hardware redundant auslegen, bzw. Halt wöchentlich? monatlich? oder sonstige zyklen das ganze noch als reguläres backup machen wenn man denn paranoid ist...


Aber mal so nebenbei meine Datenschleuder rennt seit 7Jahren, nich kein einziger HW defekt (ich nutze auch nur raid0) da ich speicherplatz benötige (aber auch egal wenn die HDD abraucht)

In der regel bist du ja auch sowieso selbst für backups verantwortlich... da kannst du ja auch dann die snapshots weg backupen
 
Naja wen ein Snapshot nicht weggesichert wird ist es halt kein Backup aber das ist meine Meinung...
 
Wer einen solchen Provider nutzt, kann doch einfach im ACP den Speicherplatz pro Nutzer auf 1 GB beschränken. Dann sieht der Nutzer sofort beim Login, ob sein Postfach bald voll ist und er unter Umständen mal aufräumen muß.
 
Ich hab mit Backup auch probleme mit 20 TB vorallem die iops sind krass und stören den Betrieb. Wie läuft das denn mit den snap shots?
 
ManDal said:
Nein habe auch schon beim ersten präsentieren der neuen Speicherart meine bedenken, denn so wird jedesmal ein komplettes Backup angelegt.

Aus meiner Sicht wäre viel besser die Option zu haben das pro Jahr oder Monat eine neue Datei angelegt wird denn aus Erfahrung wird nichts gelöscht daher ändern sich nur die "aktive" Datei (Jahr oder Monat) und man kann inkrementelle Backups erstellen. Das Daten Volumen / Backup Zeit wird so einiges kleiner...
Click to expand...
Das ist sogar eine sehr gute Idee, jeden Tag eine Datei, das wäre es <3 Aber es kommen schon änderungen wenn das ganze Postfach gelöscht wird oder der Papierkorb oder halt der Nutzer
 
You must log in or register to reply here.
Back
Top