Welches System für Backup-Programm?

  • Allgemein

Es gibt 26 Antworten in diesem Thema. Der letzte Beitrag () ist von Artentus.

    Welches System für Backup-Programm?

    Hallo liebe Community,
    ich bin gerade dara, ein einfaches Backup-Programm zu erstellen. Bisher läuft alles noch über ein einfaches System:
    Das Backup wird angefertigt (eine Zip-Datei wird erstellt, den Namen missbrauche ich als Timestamp). Nun wollte ich fragen, ob man das nicht besser machen könnte. Mein bisher größtes Problem ist, dass ich mit Gesamtdatenmengen um die 1TB zu tun habe. Diese Datenmenge setzt sich aus Abbildern der benötigten Dateien zu bestimmten Zeitpunkten zusammen. Da ist das System, dass erstmal jede Stunde, wenn möglich, ein Backup gemacht wird. Nach 2 Tagen werden alle Backups des Tages bis auf das letzte gelöscht. Das System führt sich so immer weiter (nach 2 Monaten werden die Tage zu Wochen, nach 2 Jahren die Wochen zu Monaten). Die Vorgehensweise habe ich mir übrigens nicht ausgedacht, die ist Vorgabe.
    Kennt jemand vielleicht eine bessere Möglichkeit, solche Backups zu verwalten?

    PS: Kennt jemand noch irgendwelche gut strukturierten Backup-Programme bei denen man sich etwas vom UI abschauen könnte?

    MfG Stefan

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „nafets3646“ ()

    Du kannst dir da ja vielleicht ein Beispiel am Windows-Backup nehmen. Das zerstückelt das Backup in mehrere Archive und aktualisiert dann nur die nötigen. Wie es intern funktioniert, weiß ich nicht, aber es werden auch einige Index-Dateien angelegt, damit die ganzen Archive auch nicht immer geladen werden müssen, sondern eben nur die, die upgedatet werden sollen.

    @Artentus
    Bei mir geht es nicht so um viele verschiedene Daten, die dann teilweise wiederhergestellt werden sollen oä. Es geht eher darum, automatisch eine Sicherungskopie eines Ordners zu erstellen, welche bei Bedarf entweder die aktuelle Version überschreiben oder einfach irgendwo gespeichert werden soll. Außerdem habe ich den Ansatz mit den Archiven ja schon. Oder habe ich deine Idee nicht verstanden?

    Speicherplatz ist momentan noch nicht das Problem (3TB hab ich zur Verfügung). Außerdem würde das ja zu dem System, das die Backups immer wieder reduziert gar nicht passen, oder?

    Wenn du die Backups in mehrere Archive zerstückelst, dann könntest du halt die Archive, für die eine neuere Version vorliegt, löschen. Das ist effizienter, als immer wieder alles zu löschen und neu zu packen. Das könntest du dann auch so einstellen, dass solche alten Archive nur gelöscht werden, wenn sie älter als 2 Tage sind.
    Ich nehme an, deine Vorlage ist nur, dass der Zustand aus diesen Zeitintervallen durchgehend verfügbar sein soll. Im Programm kannst dus dann als stündliche Backups anzeigen, aber speichern tust du nur das nötigste. Erhöht den Programmieraufwand, verringert die Backupgröße. Ist ja deine Entscheidung.

    Würde das Wiederherstellen dann unter Umständen nicht ein paar Stunden dauern? Wenn man irgendwann mal 100 Backups haben sollte, müsste man die ja alle durchgehen oder nicht?

    Wenn du dir ein ordentliches System zurechtlegst, also mit Index-Dateien usw., dann wird auch tatsächlich nur die nötige Datenmenge durchsucht. Die neueren Backups sind ja wesentlich kleiner, als das erste, und von den älteren Backups wird im Idealfall nur das geladen, was auch gebraucht wird.
    Wie ich ja schon sagte, der Programmieraufwand steigt (und zwar nicht unwesentlich), aber der Speicherverbrauch sinkt.
    Du hast nach besseren Methoden gefragt, ich hab dir eine genannt, ob dus auch so machs, ist ja immer noch deine Entscheidung. ;) Dein aktuelles System braucht nicht sehr viel Code, das kann ja durchaus auch ein Kriterium sein.

    Es ist mir schon klar, dass das mehr Programmieraufwand wäre. Das ist für mich aber eigentlich kein Problem, ich wüsste schon, wie ich so was umsetzen könnte. Außerdem suche ich eher nach einer Alternative für meine Zip-Archive, nicht nach einer Möglichkeit, die benötigten Speichergrößen zu minimieren ;).

    PS: Das Kriterium ist, dass es gut aussieht, intuitiv zu bedienen ist und vor allem auch schnell arbeitet.

    naja, guck dir Mercurial an, oder Tortoise (weiß nicht, was der richtige Name dafür ist) - dassisn System zur glaub Versionskontrolle nennt man das.
    Dassis übrigens Freeware, und aufgeteilt in Engine und Frontend.
    Also wenn dir deren Oberfläche nicht gefällt, kannste u.U. eine bessere schreiben.

    Eigentlich ist das ausgelegt auf Software-Entwicklung in Teams, aber wesentlicher Kern ist halt Backup-Funktionalität, und dass man jeden Stand jederzeit wiederherstellen kann. Und sie gehen effizient mittm Speicherplatz um.

    @Artentus
    Also wäre es nicht möglich, eine "richtige" Datenbank zu erstellen, die nicht nur aus einem riesigen Ordnersystem aus Archiven bestehen

    @ErfinderDesRades
    Ich würde das schon gerne selbst programmieren. Das mit dem Engine & Frontend-System habe ich auch schon umgesetzt, ich habe bisher die Core (also die Engine) und zusätzlich verschiedene FrontEnds, Konsole, WPF und WinForms (für die, die keine DirectX-kompatible GraKa haben), zusätzlich noch ein Batchscript, welches Backups erstellt und in eine Art Warteschlange einfügt, wo sie dann beim nächsten Programmstart einsortiert werden. Die Frontends sind übrigens schon alle fertig, da wollte ich eigentlich auch nicht mehr groß rumwerkeln, nur bei der WPF-Version sitze ich noch an den ControlTemplates und co. fest.

    Naja, aber dafür gibts doch dein Programm. :) Normalerweise sollte an den Backups niemand was von Hand machen. Außerdem sind so große dateien enorm unhandlich, da bekommt man immer mal wieder Probleme. Auf FAT32 kannst du z.B. gar keine Dateien >4GB anlegen.

    Ja, aber du kannst nicht wissen, welches Format der Benutzer hat. XP ist sehr oft auf FAT32 installiert.
    Außerdem machen solche großen Dateien nur Probleme. Ich hab 64Bit-Windows und ne NTFS-formatierte SSD, aber der Explorer kackt trotzdem bei Dateien, die einige Gigabyte groß sind, ab.

    Ok, dann sollte ich die Idee wohl eher lassen, oder?
    Wenn ich nochmal auf das System mit den Teilbackups zurückkomme, wäre so ein Ansatz passend?

    Quellcode

    1. Backup 1:
    2. -Dateien:
    3. -A.txt, Hash: 5645682305
    4. -B.txt, Hash: 2309375793
    5. -> Zip mit den Dateien A.txt und B.txt speichern, die Hashwerte werden auch gespeichert
    6. Backup 2:
    7. -Dateien:
    8. -A.txt, Hash: 5645682305 (gleich geblieben)
    9. -B.txt, Hash: 4603482085 (hat sich geändert)
    10. -> Zip mit der Datei B.txt speichern, für A.txt Verweis auf letztes Backup
    11. Backup 3:
    12. -Dateien:
    13. -B.txt, Hash: 7083462635 (hat sich geändert)
    14. -C.txt, Hash: 3953173597 (neu)
    15. -> Zip mit den Dateien B.txt und C.txt speichern
    17. Restore auf Backup 2:
    18. -Dateien zum Wiederherstellen:
    19. -A.txt (Backup 2 hat Verweis auf Backup 1)
    20. -B.txt (Backup 2 hat Datei direkt gespeichert)
    21. -> Datei A.txt aus Backup 1 und Datei B.txt aus Backup 2 nehmen

    Ja, so meinte ich das. Du solltest aber, wie gesagt, die Dateinamen zusammen mit dem Änderungsdatum in einer speziellen Indexdatei speichern, da du sonst alle Archive komplett entpacken musst, auch wenn die Dateien darin gleich geblieben sind. In diese Datei kannst du dann auch die Verweise auf ältere Backups einbauen.

    Eine oder mehrere Indexdateien? Ich persöhnlich hätte für jedes Archiv/jeden Backup eine angelegt, außerhalb des Archives. Es wäre jedoch auch möglich, eine zentrale Indexdatei anzulegen, diese müsste man dann aber ganz schön pflegen, damit sie nicht über deine 4GB geht, oder? :P

Facebook
Telefonspende