Neu Speicherung in SQL DB?

[SebiW]

Hallo zusammen,
wir schauen uns das Servicedesk gerade für ein kleineres Projekt an um zu sehen ob wir damit unsere bisherige Software ablösen könnten.
Allerdings stellt sich mir schon zu Anfang eine Frage. Wird die Mailkommunikation in der normalen SQL DB gesichert oder landet die in einer eigenen Datenbank?
Einerseits gehts mir um gesetzeskonforme Sicherung der Kundenkommunikation, andererseits laufen hier aber auch täglich 100e Mails ein, gerne mit großen Bildern, Anhängen etc.
Wenn das alles in der normalen SQL DB landet wird die schnell verdammt dick. Schaue ich auf unsere Mailsicherungen der letzten Jahre will ich das so eher nicht in einer DB haben die ich (zugegeben ein wenig hyperaktiv) backupe.
Danke für die Info,
SebiW

 

[Flash]

Hallo SebiW, ich weiß nicht ob es mit deinen Bedenken zu hat. Aber wir nutzen das SD nun schon 4 Wochen mit mehreren Usern mehr schlecht als recht und gerade heute ist der Zeitpunkt gekommen, wo irgendwas "voll" ist. Siehe Fehlermeldung. Kann mir gut vorstellen, dass das mit den Emails und Anhängen zusammenhängt. Jedenfalls kann nun keiner mehr mit dem SD arbeiten, brauchen dringend Abhilfe von JTL!

 

[SebiW]

Hi Flash, ja das sieht nach DB voll aus. Ooookay. Ich warte mal noch auf Feedback von JTL, aber die Mails in der Wawi DB will ich definitiv nicht.

 

[_simone_]

Hi Flash, ja das sieht nach DB voll aus. Ooookay. Ich warte mal noch auf Feedback von JTL, aber die Mails in der Wawi DB will ich definitiv nicht.

Ne, das wäre auch ein großes Manko für alle Express-User.

 

[SebiW]

Ja, das wäre für Express User sicher ziemlich schnell sehr unfein. Leider hat sich aber von JTL immer noch niemand gemeldet.
Ist ja insofern auch relevant weil Mailkommunikation nunmal gesetzeskonform 7 Jahre lang gespeichert werden muss. Dafür noch ne weitere alternative Lösung anzuflanschen habe ich mal 0 Lust.

Ceterum censeo: Das Symbol für den Servicedesk ist unglücklich gewählt. Mein erster Gedanke war: Wieso ist da ein Klo in der Symbolleiste?

 

[SebiW]

Als weitere Anmerkung, ich habe mal kurz auf unser Mailarchiv gekuckt. Da sind wir für die letzten 7 Jahre bei entspannten 100 Gig gezippt. Das will ich KEINESFALLS in der DB.

 

[Jan-Patrick Schmidt]

Hallo zusammen,

ihr könnt die Mails auslagern mit Filestreaming. Schaut euch dazu einmal dieses Video an:

 

[SebiW]

Das ändert aber ja nichts am Backup Problem. Wir machen täglich ein volles Backup (was ich für ein sinnvolles Minimum halte). Ein Full Backup speichert ja auch die Filestream Gruppen inklusive der zugehörigen Files soweit ich weiß.
Es umgeht zwar das Problem der kleinen SQLs, löst aber nicht das Problem in Verbindung mit Backups und Backupgröße.
Außerdem sind de facto alle Dateien, die im Normalfall so in Filestream abgelegt werden unterhalb der 1 MB Grenze (PDFs, Jpegs etc) und dürften damit das System deutlich ausbremsen.

Nochmal zusammengefasst: Mir geht es nicht um die 10 Gig Grenze sondern um die Frage verwaltbarer Backups. Wir haben ein jährliches Mailaufkommen von etwa 30 Gig. Aufheben muss ich das Zeug 7 Jahre.
Da reden wir über tägliche Backups von 200 Gig zusätzlich zu den normalen Daten in der DB. Das ist übel.

 

[Michael Spaltmann]

Hi,

ich dachte immer die Backupdatei wäre für Express egal und nur die MDF Datei zählt - sprich ich kann ein Backup dass größer als 10 GB ist in eine Express einspielen so lange die MDF Datei am Ende kleiner als 10 GB ist. Das löst natürlich nicht das Problem, dass bei Euch so oder so riesige Datenmengen anfallen. Da würde ich dann sowieso von Express abraten.

Wir haben das mit dem Filestream extra eingebaut damit Express-User den Servicedesk nutzen können. Wäre ärgerlich wenns dann am Backup scheitert.

@Flash Habt ihr das mit dem Filestream mal probiert?

Grüße Michael

 

[SebiW]

Hallo Michael,

wir haben einen Standard Server. Das ist nicht mein Problem.
Mein Problem ist, dass die Daten Teil der normalen Wawi DB sind. Das heisst auch, dass bei einem Fullbackup (dürfte zb auch vor jedem Eurer Updates durchlaufen, oder) eine brachiale Menge an Daten bewegt werden muss.
Unseres Mandanten stehen derzeit alle so zwischen 5 und 20 Gig. Das ist noch sinnvoll machbar.
Werden daraus 200 GB sind tägliche Fullbackups, externe Sicherungen bspw in der Cloud und vieles mehr ein echtes Problem.

Eine vernünftige Sicherungsstrategie für die Geschäftsdatenbank setzt aber nunmal ohne Wenn und Aber regelmässige (imho MINDESTENS tägliche) Backups an mehreren Speicherorten voraus.
Bei den Mails kann ich sehr gut mit weniger aggressiver Speicherung leben, da habe ich im Zweifel immer noch Backups des Mailservers.
Beide Bereiche in eine gemeinsame Sicherungsstrategie zu zwingen ist undurchdacht.

Ich wollte das Ding eigentlich testen, aber so ist der Servicedesk für uns und wahrscheinlich auch viele andere nicht einsetzbar.

Gleich eine weitere Frage: Wie steuert Ihr welche Daten via Filestream ausgelagert werden? Wenn ich Filestream einrichte und mein Backupmodell auf ein Partial Backup umstelle um obiges Problem zu umgehen, liegen dann auch alle meine Bilder im Filestream und sind im Ernstfall bei einem Wiedereinspielen der Partial Backups erstmal weg?

 

[hula1499]

Wir kriegen täglich rund 200 MB an Bildern via Ticketstystem * 365 = ~70GB / Jahr...
Das Ticketsystem bläht somit alles extrem auf, Backups und Backupverteilungen (intern/extern/etc) würden das xxfache an Zeit und Performance kosten, wenn alles durchgemischt ist.
Periodische Sicherheitsvollbackups wären dann der Hammer (derzeit 7 Tage bei uns).

Beide Bereiche in eine gemeinsame Sicherungsstrategie zu zwingen ist undurchdacht.

Absolut richtig.
Ohne komplett autarker DB ist es auch für uns ein absolutes no-go, egal wie toll es vielleicht werden wird.

 

[SebiW]

Ich glaube worauf es hinausläuft: Euer Servicedesk skaliert in der jetzigen Form nicht.

Ihr baut mit diesem Datenkonzept ein Tool, das für Neulinge attraktiv, für diejenigen Eurer Kunden, deren Firmen bereits etabliert sind, aber sehr viel unattraktiver ist.
Und das sind diejenigen Kunden, die im Zweifel auch mehr als einen Mandanten brauchen und das Projekt damit überhaupt erst fiskalisch sinnvoll machen.

Imho solltet Ihr über die Art der Datenspeicherung dieses Moduls dringend noch einmal nachdenken.
Kann es vielleicht sein, dass das Datenvolumen da ein klein wenig unterschätzt wurde?

 

[_simone_]

Wir sehen das ähnlich wie unsere Kollegen hier im Thread: Mit ext. DB würden wir testen, ansonsten nicht.

 

[Verkäuferlein]

Auch bei uns das Gleiche, der nächste Punkt wird dann ja auch die Rechnungsspeicherung (PDF) im Zusammenhang mit GoBD-konformer Rechnungsstellung in der Wawi.

Es wäre da sehr sinnvoll, entweder Servicedesk und Rechnungen jeweils in eigene Datenbanken zu packen, die sich gesondert sichern lassen oder aber eine pauschale "Kundenakte" anzulegen.

Cool finde ich auch den Ansatz von Greyhound, dass man im Prinzip eine komplette "Kundenakte" hat und diese erstellen kann und dies auch jederzeit unabhängig von dem eigentlich Programm als Archiv abspeichern und auch lesen kann.

Eigentlich muss JTL genau dahin und als Steuerungszentrale CRM- und DMS-Funktionen direkt integriert weiter ausbauen, die Daten aber auch getrennt oder als vollständige "Kundenakte" exportier bzw. sicherbar machen.

 

[SebiW]

Ja, genau darüber habe ich bei der GoBD Ankündigung auch schon nachgedacht. Das auch noch oben draufgepackt und wir können aufhören zu arbeiten weil der Server den ganzen Tag mit Backups beschäftigt ist

 

[Michael Spaltmann]

Hi,

@SebiW: In der 1.5 werden tbilder, tfile und tbestelldokument zusätzlich zu html und Anhängen des Servicedesks ausgelagert. In der 1.6 werden es wohl noch mehr werden, aber ich kann dir jetzt noch keine genauen Angaben machen da sich das noch alles ändern kann. Ich habe auch nochmal Rücksprache mit unseren Team-DB Kollegen gehalten und die raten von partial Backups ab - hier müsstest Du dann ein komplett eigenes Backupkonzept fahren bei dem wir dich im Ernstfall nur schlecht supporten könnten.

Ich habe Euer Feedback aufgenommen und werde es an die entsprechenden Stellen weitergeben. Das die Datenbankgröße durch den Servicedesk aufgebläht wird hatten wir schon recht früh auf dem Schirm und uns deshalb für den Weg mit Filestream entschieden. Falls das nicht zum Ziel führt müssen wir uns hier natürlich nochmal mit auseinandersetzen.

Viele Grüße
Michael

 

[SebiW]

Hallo Michael,

schön dass Ihr das Feedback aufnehmt. Ich glaube die zentrale Geschichte die Euch klar sein muss ist, dass wir hier bei größeren Firmen ganz schnell über eine Vervielfachung der DB Größe reden.
Wie gesagt, bei uns sind das konservative 30 GB pro Jahr. Bei @hula1499 ist es mehr als doppelt so viel.

Das ist in die normalen Sicherungskonzepte der Wawi DB nicht sinnvoll zu integrieren und erschwert definitiv die Verwendung dieses Tools ab einer gewissen Firmengröße massiv.
Ich kann mir kaum vorstellen, dass das Euer Ziel ist.

Ihr müsst auch und gerade, wie von @Verkäuferlein erwähnt, in Verbindung mit der neuen GoBD Speicherung tierisch aufpassen, dass die DBs da nicht im Akkord Richtung dreistellig explodieren.
Stand jetzt gehe ich von etwa ~250 KB für eine ZUGFeRD konformes PDF aus. Da ist man bei 100k Rechnung pro Jahr schnell bei 25 GB pro Jahr. Speichern muss man den Quatsch 10 Jahre lang.
Nimm man 7 Jahre 30 GB Mails dazu steht man nach diesen sieben Jahren bei einer DB mit fast 400 GB. Das ist nicht darstellbar.

 

[Jens Falk]

Hallo,

ich halte es nicht für sinnvoll ein Ticketsystem bze. den JTL-ServiceDesk GoBD-fähig machen zu wollen. Dafür gibt es Mailarchive.

Es empfiehlt sich Rechnungen, egal ob Eingang- oder Ausgang, mit den anderen Dokumenten die aufbewahrt werden müssen, in ein DMS zu schicken. So ist alles zentral an einem Ort und macht einen Prüfungsvorgang weniger zeitintensiv.

Mails zum Dateiversand zu nutzen ist auch keine gute Idee, dafür gibt es Filelink-Systeme, siehe Funktion in Thunderbird.

Service-Desk sollte die normale Kommunikation mit dem Endkunden, bzw. Lieferanten abbilden. so wie von JTL angekündigt. In den meisten Fällen sind das Serviceanfragen oder E-Mail-Bestellungen und ähnliches, also Mails mit max. 10 KB.

Die Auslagerung mit Filestreaming finde ich einen guten Kompromis für Nutzer mit der Express-Version.

Bleibt gesund!

Jens Falk

 

[hula1499]

In den meisten Fällen sind das Serviceanfragen oder E-Mail-Bestellungen und ähnliches, also Mails mit max. 10 KB.

Ja, du hast natürlich recht.
Alles über 10kb dann gleich am besten vom Mailserver her blocken, oder?

 

[Jens Falk]

Ja, du hast natürlich recht.
Alles über 10kb dann gleich am besten vom Mailserver her blocken, oder?

Nein, weiterleiten an eine andere Adresse und verwerfen. Und diese Adresse dann mit einem Ticketsystem bearbeiten. Ich empfehle Freescout, gibts auch deutschsprachig.