Datenbankgröße optimieren

Beantwortet

Kommentare

13 Kommentare

  • Offizieller Kommentar
    Avatar
    Holger Büttner • ProSaldo GmbH (Bearbeitet )

    Sehr geehrter Herr Kaufmann,

    "Datenbank duplizieren" ist der Weg zur Größenoptimierung. Wie sinnvoll es ist in einer Datensicherung nicht alle Inhalte vorzuhalten, ist fraglich.

    Das Laden der so optimierten Datenbank auf den cubeSQL Server erfolgt ausschließlich wie im Handbuch beschrieben via MonKey Office, damit kommen Sie gar nicht in den Konflikt mit der Datenbankverschlüsselung.

     

     

    Aktionen für Kommentare Permalink
  • Avatar
    Tim Kaufmann

    Hallo Herr Büttner,

    danke für Ihre Nachricht. Vielleicht ist das ein Missverständnis meinerseits. Ich dachte, dass ich bei der Transaktion lediglich Anhänge verliere, die ich ohnehin wiederherstellen kann, sieht man mal von der Handvoll PDFs ab, die wir über die Jahre angehängt haben. Mache ich einen Fehler?

    Danke für den Handbuch-Link. Ich hatte dort gelesen, das aber nicht auf meinen Fall bezogen sondern nur auf die Ersteinrichtung.

    Viele Grüße

    Kaufmann

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Typereym

    Guten Tag Herr Kaufmann,

    der Schlüssel wird bei der Installation auf den CubeSQL-Server unverschlüsselt übertragen. Sie können also den geheimen öffentlichen Schlüssel also gerne selber auslesen und damit direkt auf Ihre Daten zugreifen.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Stefano Kowalke (Bearbeitet )

    Moin,

    was Typereym beschreibt mag technisch möglich sein, würde ich aber nicht empfehlen. Die ganze Businesslogik befindet sich in Connect bzw. MonkeyOffice und nicht in der Datenbank. Durch den direkten Zugriff auf die DB läuft man Gefahr die DB nachhaltig zu zerstören, weil Plausibilitätschecks nicht ausgeführt werden und Querverweise zwischen den Tabellen nicht bekannt sind. 

    Zum eigentlichen Thema:

    Warum stellt eine 500 MB große Datenbank ein Problem für euch da? Man kann die

    1. komprimieren und 
    2. als "rollendes Backup" gestalten,

    dann haltet ihr lediglich die letzten N Backups vor. Mit der Mac-Software "Hazel" kann der Prozess sogar automatisiert werden (wenn man nicht mit CronJobs hantieren möchte).

    /cc Tim Kaufmann

    Beste Grüße
    Stefano

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Tim Kaufmann

    Hi Stefano,

    wir pumpen das Backup in die Nextcloud und synchronisieren das an einen zweiten Standort. Das ist dann einfach ordentlich Holz. Das wäre nicht wild wenn mir das nicht so ineffizient erschiene. Du hast (grob)

    1. Buchungssätze (kosten "keinen" Platz)

    2. Adressdaten (kosten "keinen" Platz)

    3. Vorlagen (scheint mir auch "keinen" Platz zu brauchen, sind nur sehr wenige und die scheinen mir nur aus der Template Sprache, also Plaintext zu bestehen)

    4. Jede Menge PDFs (kosten ordentlich Platz)

    Versioniere Änderungen an #1-#3 in der Datenbank, dann kannst du #4 jederzeit neu generieren und musst das nicht mitsichern. Will hier nicht klüger sein als die Henne, gut möglich dass es Gründe für das Verhalten gibt, finde es einfach spannend das mal so zu diskutieren.

    Liebe Grüße

    Tim

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Typereym (Bearbeitet )

    Hallo Stefano,

    du kannst ja auch direkt mit cubeSQL auf die Datenbank zugreifen und die Datenbank nachhaltig zerstören, Verschlüsselung hin oder her. 

    Die Verschlüsselung hat aber durchaus mit dem Thema zu tun, denn du kannst verschlüsselte Daten (wenn du nicht AES im ECB-Modus verwendest) nicht komprimieren.

    PS: Die Verschlüsselung kannst du auch ohne Schlüssel mit dem DECRYPT-Befehl über den CubeSQL-Server deaktivieren.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Stefano Kowalke (Bearbeitet )

    Hallo Typereym,

    mir ging es weniger um die Verschlüsselung, sondern mehr darum auf die Gefahr hinzuweisen, dass der Zugriff auf die DB ohne Connect oder MO die DB nachhaltig beschädigen kann.


    ... denn du kannst verschlüsselte Daten (wenn du nicht AES im ECB-Modus verwendest) nicht komprimieren.

    Ich kann nicht den ganzen Ordner mit den .sdb-Dateien drin "zip"en oder "tar"en, weil die Daten darin verschlüsselt sind?

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Typereym

    Hallo Stefano,

    du kannst die .sdb-Datein zwar mit zip oder tar archivieren, aber nicht komprimieren. Das kommt daher, dass die Entropie zuverlässig verschlüsselter Daten gleich der Entropie pseudo-zufälliger Daten ist.

    Ganz genau genommen, machst du die Dateien mit dem archivieren sogar noch (geringfügig) grösser, weil noch weitere Metadaten hinzugefügt werden.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Stefano Kowalke

    Moin Typereym,

    gerade mal getestet. Sind beide gleich groß. Wieder was gelernt. Merci dafür!

    0
    Aktionen für Kommentare Permalink
  • Avatar
    Typereym

    Ciao Tim,

    die Diskussion ist was abgedriftet... Noch eine kurze Anmerkung zum Punkt 4:

    4. Jede Menge PDFs (kosten ordentlich Platz)

    Es ist verlockend zu denken, dass die Dokumente zu jedem Zeitpunkt einfach neu generiert werden könne. Diese hängen jedoch vom Stand der Datenbank ab und du kannst nicht sicherstellen, dass du ein Dokument zu einem anderen Zeitpunkt wieder generieren kannst. Es ist also durchaus Sinnvoll, die Dokumente in der Datenbank direkt zu speichern.

    Bei uns ist es aber so, dass wir die Mails über Google Workspace versenden und diese Mails landen automatisch im Postausgang des Mailkontos. Wir löschen gelegentlich die gesendeten Mails aus MO, weil noch eine Kopie im Google-Postfach liegt. Ob über SMTP gesendete Mails im Postausgang landen hängt vom Anbieter ab.

    Wenn Daten gelöscht werden, können freie Blöcke mitten in der Datei entstehen. Daher bleibt die Datenbankgrösse erhalten, auch wenn viele Daten gelöscht wurden. Mit VACUUM kann SQLite diese Lücken schliessen und Speicherplatz freigeben. (Achtung, VACUUM und auto_vacuum machen nicht das selbe). Bei VACUUM wird eine neue Datenbank erstellt und die Daten in diese neu eingefügt.

    0
    Aktionen für Kommentare Permalink
  • Avatar
    OKNU (Bearbeitet )

    MIT Datei in Cloud beim den grösserer Anbieter soll man aufpassen!

    Weil wen da etwas ist ein Bild in ein Konto , Datei die Zuviel gegen deren Vertrags Bedingungen verstossen.

    Kann es sein alles nicht mehr erreichbar, ist mehrmals passiert war in Nl in die Presse.  ( Selbst Microsoft Accounts und co)

    Die Filter laufen Automatisch da sollte man besser kein "witzige" Bilder und andere Sachen in solche Accounts irgendwo Speichern oder teilen zum Beispiel.

    Wichtig:

    Den Backups soll man also immer auch offline lokal selbst haben müssen!  Ist übrigens auch nicht erstes wo den Datei und Backups Cloudanbieter weg sein können wegen Störung , fehler oder hacks.

     

    ;)

     

    OJA Backups ( Medium Disks... )  von Netzwerk getrennt auch offline andere Location aufbewahren.

    Ein Backup Ohne Restore test ist eigentlich gleich an KEIN BACKUP!

    Backups zugänglich in Netzwerk sind auch nicht wirklich Backups. (Ransomware und co)

    Dieser in Doku festlegen und den Restore auch ohne eigene Infra öfter zwischendurch testen und die Test in Doku.

     

    Mit ein gelungene Ransomware ist man auch den Cloud Workspace , Backups in Cloud und co .... :(

     

    Wirklich sichere Backups sind meiner Meinung nach nur den auf Lokale  Media und OFNETZ anderer Location in einem Safe mit den Zugang Safe ofcourse Audited.

    Cloud Backups wer weis was wo wirklich steht und ob dieser nicht gegen Datenschutz und co ist weil Zugang von Ausland Behörde oder anderer Ohne Vertrag ein Abi oder so, die man sagt ...  Egal ob verschlüsselt wen die Datei in andere Händen geraten kann dan..

    0
    Aktionen für Kommentare Permalink
  • Avatar
    ds

    Hallo Zusammen,

    die Diskussion driftet mal wieder ab ...

     

    4. Jede Menge PDFs (kosten ordentlich Platz)

    Wie Typereym schon schrieb wird die Druck-Ausgabe in MO durch diverse Faktoren (Programmänderungen, Konfiguration, Formulartyp/änderungen, OS?, ...) beeinflußt, so dass man nach ein paar Monaten nie sicher ein Dokument reproduzieren kann.

    Versioniere Änderungen an #1-#3 in der Datenbank

    Eine Versionierung der o.g. Faktoren wird wohl die Resourcen von MO überfordern.

    Um etwas mehr Sicherheit zu haben, bietet sich daher die Erstellung von PDFs an, da diese nicht so leicht geändert werden können. Da PDFs jedoch relativ viel Platz einnehmen, sehe ich hier schon auch ein Problem in den mangelhaften Wartungs- und Archivierungsmöglichkeiten der MO-Datenbank.

    Auch wenn man sich dazu entscheidet, Anhänge möglichst als Verknüpfungen anzulegen, kann man PDFs nie ganz vermeiden (z.B. Emails mit Anhängen). Hinzu kommen dann natürlich auch die "normalen" Daten und Vorgänge. D.h. heißt letztendlich, dass die MO-Datenbank über die Jahre kontinuierlich anwächst und es zur Zeit keine Möglichkeit gibt die Datenbank "aufzuräumen" (das DB-Duplizieren ohne Anhänge ist mit Datenverlust behaftet und löst auch nur ein Teil des Problems und ist folglich auch keine Lösung).

    Ich würde mir für die Zukunft wünschen, dass man bestimmte Jahre aus der "produktiven" Datenbank komplett "exportieren/archivieren" kann und die Daten in eine getrennte Backup-Datenbank ausgelagert werden. Die Produktiv-DB bleibt auf diese Weise schlank und bei Bedarf kann die Archiv-DB als eigenständiger Import eingelesen werden.

    Schönen Gruß

    0
    Aktionen für Kommentare Permalink
  • Avatar
    OKNU (Bearbeitet )

    die Diskussion driftet mal wieder ab ... SORRY nur für die hier den Beitrag finden und lesen egal welche USER. gedacht also wegen Backups im algemein.  ;)

     

    UND JA man sollte ältere Jahren in ein Archiv Möglichkeit haben dieser verarbeitet in / unter / beim den BACKUP RESTORE.

     

    So wie es zum Beispiel TOBIT/DAVID macht also dieser auch nur denen die dafür den Rechten zugewiesen sind!  Dieser anlegen können / ändern (path, name und co) und oder nur aufrufen

    0
    Aktionen für Kommentare Permalink

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.