*.tinydms Datei recht groß

  • Da ich auch zurückliegende Jahre in mein DMS aufgenommen habe, ist die *.tinydms - Datei mittlerweile 2,5 GB groß. Genauso viel Speicher verbraucht Der Datei-Ordner mit den Dokumenten. Etwas nervig ist das tägliche Synchronisieren für Backups: ,Während Neue Dokumente einzeln, also in Sekundenschnelle, gesichert werden, dauert die Sicherung der tinydms-Datei mittlerweile fast 2 Minuten. Wenn ich also wie vorgeschrieben die Buchhaltung der letzten 10 Jahre im DMS halte, wird jede Sicherung dann 5 Minuten dauern.


    Besteht die gefahrlose Möglichkeit, "alte" Jahre aus der *.tinydms-Datei zu entfernen, wenn ja wie?

    Könnten man die Datei schon Programmseits in Jahre aufteilen?

    Ich fände es praktischer, wenn die DMS-Datei nach Jahren aufgeteilt würde (Firma-2018, Firma 2019 usw.) Dann würden bei jeder Datensicherung nur eine veränderte tinydms-Datei mit den Daten EINES Jahres gesichert, nicht eine geänderte Datei mit den Dokumentdaten von 10 Jahren.


    Oder sollte ich da prinzipiell anders vorgehen?

  • Ja, alles Belege. Bei mir sind es die Belege von 4 Jahren. Ich habe (USB-Version) einen Ordner Dokumente, dorthin werden wohl die eingescannten oder der Buchung zugeordneten Belege kopiert. Dieser Ordner hat 2,5 GB. Die Datei Firma.tinydms hat 2,8 GB. Das meiste werden wohl die Belege sein.


    Der Programmstart und das Buchen geht recht flüssig, aber Sicherungen (Backups) sind so recht zeitintensiv, statt einiger weniger Belege und einer bei mir dann max. 0,7 GB großen Datei (2,8/4) wird immer das DMS-Archiv aller Jahre geändert und dann natürlich auch synchronisiert.

  • Für eine Lösung des "Problems" wäre ich sehr dankbar. So lange in Vorjahren nichts mehr geändert wird oder "neue" Belege dazukommen, macht es irgendwie nicht recht viel Sinn, 4 Jahre alte Belege, jedes mal neu zu synchronisieren (Backups anzufertigen) obwohl sich gar nichts geändert hat...

    • Official Post

    Hallo Trotzdem,


    wo hast Du die Datei abgelegt? Bei mir wird diese nicht in die Komplettsicherung mit aufgenommen.


    Generell bei so großen Dateien ist eine komplette Sicherung unpraktisch, da die Datenmenge schnell anwächst.


    Dazu gibt es verschiedene Möglichkeiten, dropbox übertragt z.B. nur die Änderungen und man hat dann verschiedene Versionen auf dem Backupserver, die man wiederherstellen kann.


    Dabei ist die Dateigröße egal, Du kannst auch eine 1TB große Datei syncen.


    Aber um die Differenzen zu erkennen, muss das Wolkenprogramm auch jedesmal die komplette Datei scannen, was dauert.


    Dabei ist das Problem, dass die .tinydms-Datei nicht im laufenden Betrieb extern gesichert werden sollten, d.h. es muss Taxpool zuvor beendet sein, oder Taxpool kopiert die Datei.


    Eine zweite Sicherungsfunktion für die tinydms-Datei ist deswegen in Vorbereitung.

    Zu den einzelnen Belegen, ich würde die Belege nicht in die Komplettsicherungen einbinden, wenn es sich bereits um GB's handelt, sondern mit einem Backupprogramm wie rsync/Borg Backup/Duplicati auf ein anderes Laufwerk oder auch vorab verschlüsselt mit SFTP auf den eigenen Server oder in die Cloud laden.

    Das geht recht schnell.

  • wo hast Du die Datei abgelegt?

    Ich habe alles auf einem USB-Stick, den ich komplett sichere. Die *.tinydms befindet sich im Hauptordner von Taxpool auf dem USB-Stick, also im selben Ordner wie das Programm. Sonst kann das Programm ja nicht darauf zugreifen, wenn ich den USB-Stick an (m)einen anderen PC stöpsele.


    Über die Cloud mache ich nichts.


    Den kompletten USB-Stick synchronisiere ich über FreeFileSnyc. Und das hängt immer ewig an der *.tinydms.

  • dropbox übertragt z.B. nur die Änderungen

    Quote

    Nach den jüngsten Erleichterungen der deutschen Buchführungs- und Aufbewahrungspflichten kann nun ausnahmsweise die digitale Verarbeitung und elektronische Speicherung von Unternehmensdaten außerhalb Deutschlands durchgeführt werden – z.B. durch die Nutzung von Cloud-Anwendungen. Dies erfordert jedoch die vorherige Genehmigung eines begründeten Antrags durch das Finanzamt.

    https://www.pwc.de/de/technolo…-des-cloud-computing.html


    Um umfassende Dokumentationspflichten zu meiden und turnusmäßigen Rechtsänderungen aus dem Weg zu gehen ist mir die USB-Lösung derzeit die liebste. Cloudserver in Deutschland kosten schon ordentlich, meines Wissens ein vielfaches mehr als das Programm Taxpool selbst.


    Zumal auch Taxpool selbst sicher beschleunigt würde, wenn abgeschlossene Wirtschaftsjahre auch in der *.tinydms abgeschlossen wären. Selbst wenn nachträglich Dokumente eingepflegt würden, würden sie ja keinen alten sondern einen aktuellen Timestamp erhalten.


    Last but not least würde sich auch ein nie ganz auszuschließender Daten-Supergau in einer einzigen Datei sich nicht automatisch auch auf sämtliche darin abgespeicherten Dokumente aller (Vor-) Jahre auswirken sondern nur auf das aktuelle Dokumentenjahr.

    • Official Post

    FreeFileSnyc kannte ich noch nicht, schaue ich mir mal an. Kann man es per Kommandozeile mit einer Configdatei starten?


    Du könntest dort ja zwei Sicherungsstasks einrichten, täglich für Belege, wöchentlich für *.tinydms.


    Ist denn der Stick schnell genug?


    Du kannst auch für jedes Wirtschaftsjahr eine neue Datei anlegen um die Größe aufzuspalten.


    ***Um umfassende Dokumentationspflichten zu meiden und turnusmäßigen Rechtsänderungen aus dem Weg zu gehen

    Wichtig ist generell, dass die Daten vorab sicher verschlüsselt sind, insbesondere auch wegen der DSGVO.

    Deswegen darf in diesem Fall nicht das Standardpasswort verwendet werden.

    Für Cloud gilt außerdem, immer nur eine Kopie der Daten, die bei Dir als Original liegen, sichern, bei einem technischen Fehler, Hack, Accountsperrung, ... ist ansonsten die Datenhoheit und/oder alle Daten verloren.


    ***Cloudserver in Deutschland kosten schon ordentlich

    Hetzner hat z.B. preiswerte Storage-Boxes.

    Wobei man allerdings bei dem Preis keine Werte wie bei Amazon AWS erwarten darf.

    Quote

    ..Schutz von Backups mit 99,999999999 % Zuverlässigkeit von Daten. Kopien aller in Amazon S3 und Amazon S3 Glacier hochgeladenen Daten werden auf mindestens drei Geräten in einer einzelnen AWS-Region erstellt und gespeichert...

    Trotzdem sollten noch mindestens zwei weitere unabhängige Backups existieren, z.B. lokal, (DVD oder M-Disc).

  • Besteht die Möglichkeit, dass Sie hier über zweierlei Programmfeatures schreiben?

    Wenn das DMS benutzt wird, um Belege usw. zu sichern entsprechend den GoBD, dann werden alle Dokumente in einer einzigen Datenbank gespeichert resp. gesichert. Die kann auch (leider) nicht teilweise gesichert werden nach dem Motto, Buchungen täglich, Belege wöchentlich und das letzte Jahr nur bei einer Änderung.


    Ich wüsste auch nicht, wie dies datentechnisch zu realisieren wäre, wenn gleichzeitig über die "Festschreibung" dokumentiert werden soll, dass es sich um Originaldaten handelt.


    Deshalb gehe ich her, mache meine vollständigen Sicherungen nach jeder Nutzung des Mandanten und begrenze diese aus Platzgründen auf wenige Versionen auf der aktuellen Festplatte. Von dieser Festplatte erfolgt dann die endgültige Sicherung auf eine Archivplatte resp. in einen Cloudspeicher.


    Auch hier ist es sinnvoll, die Generationen beizubehalten, denn sonst müsste vor dem Löschen einer Generation geprüft werden, ob die nachfolgende keinen technischen Datenfehler enthält und unlesbar ist.


    Allerdings fehlt m. E. im DMS noch die Möglichkeit, den Ablauf der Aufbewahrungspflicht vorzugeben und danach die Daten effektiv zu löschen. Dies ist eine Pflicht nach der DSGVO, soweit es sich um personenbezogene Daten handelt.


    Die Belege unabhängig von den Buchungen zu sichern ist m.E. nur möglich in der bisherigen Dokumentenverwaltung, wenn die Belege nicht in das Dokumentenverzeichnis kopiert werden. Dies entspricht aber nach herrschender Meinung nicht den GoBD, die schon zu beachten sind, wenn bspw. Umsatzsteuerpflicht besteht.

    Software: Taxpool mit Postgres in Bilanz- und EÜR Version; Online-Banking über Subsembly
    Kontenrahmen: SKR 03 / 04 / 42 / 49 ; Wunsch wäre SKR 14
    mehrere Mandanten,

  • Allerdings fehlt m. E. im DMS noch die Möglichkeit, den Ablauf der Aufbewahrungspflicht vorzugeben und danach die Daten effektiv zu löschen

    Es geht mir um das DMS, und nicht um dessen Backup. Da ist mir nur aufgefallen, wie groß die Datei in 10 Jahren wird. Spätestens dann muss ich ja alte Jahre, für die die Aufbewahrungsfrist abgelaufen ist, aus der DMS-Datei "raus bekommen".Ich hab einen kleinen Betrieb mit unter 2000 Buchungen im Jahr, schon da sammeln sich viele Belege - und damit eine große Datei - an.


    Aus mehreren Gründen ist eine einzige Datei unglücklich:

    • Ich werde in 15 Jahren die DMS-Datei von 19 Jahren haben, obwohl 8 Jahre davon dann überflüssig und - stimmt - auch datenschutztechnisch - gelöscht gehören.
    • Unwahrscheinlich, aber bei einem Stromausfall beim Schreiben kann die DMS zerschossen werden. Dann ist nicht nur das aktuelle Jahr hin, sondern alle Jahre im DMS. Sehr unwahrscheinlich, und mit regelmäßigen Backups beläuft sich der Schaden auch nur auf eine Woche. Gut gelöst ist es aber nicht.
    • Ich hatte eigentlich vor, jetzt jedes Jahr "für sich" zu buchen aber ein Blick auf die Vorjahre ist gelegentlich hilfreich, und wer Coronahilfen in Anspruch nimmt muss aktuell bis auf 2019 zurückblicken können. Da möchte ich nicht mit unterschiedlichen Dateien operieren, die Buchungsdatenbank ist ja flott genug, auch mehrere Jahre in einer Datei zu halten.
    • das Festschreiben der Beleg dauert mittlerweile ebenfalls recht lange, auch das ist sicher der mehrjährigen Datei geschuldet.
    • Official Post

    An Bernhard: Das Löschen wird sicher noch kommen, dabei wird aber die Datei nicht kleiner, bei festgeschriebenen Daten wird nur der Schlüssel 'weggeworfen'.


    An Trotzdem:

    Quote


    aber bei einem Stromausfall beim Schreiben kann die DMS zerschossen werden


    Die sqlite-DB arbeitet mit dem höchsten sync (EXTRA):

    Quote

    EXTRA (3) EXTRA synchronous is like FULL with the addition that the directory containing a rollback journal is synced after that journal is unlinked to commit a transaction in DELETE mode. EXTRA provides additional durability if the commit is followed closely by a power loss. FULL (2) When synchronous is FULL (2), the SQLite database engine will use the xSync method of the VFS to ensure that all content is safely written to the disk surface prior to continuing. This ensures that an operating system crash or power failure will not corrupt the database. FULL synchronous is very safe, but it is also slower. FULL is the most commonly used synchronous setting when not in WAL mode. NORMAL (1) When synchronous is NORMAL (1), the SQLite database engine will still sync at the most critical moments, but less often than in FULL mode. There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in journal_mode=DELETE on an older filesystem. WAL mode is safe from corruption with synchronous=NORMAL, and probably DELETE mode is safe too on modern filesystems. WAL mode is always consistent with synchronous=NORMAL, but WAL mode does lose durability. A transaction committed in WAL mode with synchronous=NORMAL might roll back following a power loss or system crash. Transactions are durable across application crashes regardless of the synchronous setting or journal mode. The synchronous=NORMAL setting is a good choice for most applications running in WAL mode. OFF (0) With synchronous OFF (0), SQLite continues without syncing as soon as it has handed data off to the operating system. If the application running SQLite crashes, the data will be safe, but the database might become corrupted if the operating system crashes or the computer loses power before that data has been written to the disk surface. On the other hand, commits can be orders of magnitude faster with synchronous OFF.

    Die sqlite-DB sollte am Besten nicht auf einem Netzlaufwerk betrieben werden.


    Ich antworte in 1-2 Wochen noch weiter, es ist ein Update in Aussicht, bei dem die Datenbank in Einzelteilen gesichert werden kann.

    Beispiel: Es wird eine Datei eingescannt und in das DMS eingefügt, Taxpool kopiert dann die neue Datei im Format der Datenbank in einen anderen Ordner.


    Es müssen aber dann alle Teile gemeinsam aufbewahrt werden.

    Aus verschiedenen Gründen wird ein Zeitstempel für mehrere Dateien gleichzeitig erzeugt, die Checksumme ergibt sich dann aus der Summe der Checksumme jeder einzelnen Datei, d.h. bei der späteren Prüfung müssen alle beteiligten Dateien mit der zum Zeitpunkt der Erstellung des Stempels gesicherten Checksumme vorliegen, fehlt eine Datei oder wurde Sie verändert (mit Datenbankmitteln)/beschädigt, erscheint eine Fehlermeldung.

    Aber auch ohne Zeitstempel gibt es Abhängigkeiten zwischen den festgeschriebenen Dokumenten, die geprüft werden können.


    Eine andere Möglichkeit der Datensicherung:

    postgres-server-Installation (lokal oder auf einem anderen Rechner, oder auf einem raspberry-PI (wenig Stromverbrauch)):

    https://www.taxpool.net/HTML/postgresql_datenbankcluster_erstellen.htm

    Dort einen Task einrichten, der zyklisch sichert:

    pg_dumpall

    Die Beträge des Autors dienen ausschließlich dem Zweck der Information oder Meinungsäußerung und stellen keine rechtliche oder andersweitige Beratung oder Zusicherung dar.

    Änderungen und Irrtümer sind vorbehalten.

  • UI.


    Erst mal Danke, ich warte lieber mal ab, da ich von Server-Installation etc. leider nichts verstehe. Momentan dauert das sichern 3 Minuten, in der Zeit kann ich ja dann etwas anderes machen.


    Ich habe alles auf einem USB-Stick, das würde ich gerne beibehalten. Dadurch ist ja auch gewährleistet, das ich auf zurückliegende Jahre jederzeit zugreifen kann und alle Daten integer sind. Eine Aufteilung der Daten in Wirtschaftsjahre, analog zur Buchhaltung, wäre früher oder später vielleicht von Vorteil.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!