*.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?

  • Hi,


    welche Dateien im Dateiordner verbrauchen den meisten Platz, handelt sich dabei um Belege?.

    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.

  • 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...

  • 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.

    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.

  • 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.

  • 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).

    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.

  • 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.

  • 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.

Participate now!

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