Strongbox - Best Practice

  • Hallo zusammen,

    zur Zeit spinnt unsere Strongbox-Sicherung, dass am Wochenende teilweise die Platte voll lief und Montagfrüh dann nix mehr ging. Leider finde ich keine Ursache dafür, was die großen Datenmengen verursacht... :/

    Gibt es eine Best-Practice Lösung oder Denkansätze?

    Aktuell bei uns:

    BackupExec sichert am Freitag um 23:55 ein Vollbackup aller Server etc.
    Strongbox sichert erst Samstag ein Basis-Image (Abends) und dann So-Fr inkrementell (Abends).
    Überschreiben ist auf 4 tage gesetzt.

    Wäre es dann nicht eher sinnvoll das Basis-Image auf Freitag zu verlegen?
    Beeinträchtigt der Strongbox-Job das normale Arbeiten? Normal dürfte um die Zeit (sagen wir mal ca. 18:45) keiner mehr da sein.


    Danke für eure Hilfe


    Seb

  • also was jetzt die letzten zwei Wochen schief gelaufen ist - keine Ahnung ehrlich gesagt. Kam aus heiterem Himmel die Probleme


    Werde jetzt mal testweiße am Freitag alles zurück setzen und die Einstellungen anpassen:

    Basis-Image - Freitag - ab ca. 19 Uhr

    Inkr-Image - restliche Tage ab ca. 19 Uhr

    Überschreiben 1 Tag

  • Auf was für einem Server (Windows Server Version) habt Ihr das laufen?

    Man kann solche StrongBox Desaster ab Windows Server 2016 recht gut im Zaum halten indem man schlicht Deduplizierung aktiviert und passend konfiguriert.
    Best-Practice ist allerdings das die StrongBox Sicherung ein eigenes Laufwerk zugewiesen bekommt, auf dem nichts anderes als StrongBox Sicherungen abgelegt werden.

    Stellt man dann die Deduplizierung so ein, das sie bereits nach 1 Tag und auch auf aktuell geöffnete Dateien angewendet wird und das partielle Files optimiert werden sollen, verringert sich der reale lokale Platzbedarf von StrongBoxen drastisch.

    Hier ein Link zu einem Microsoft Dokument bezüglich der Einstellmöglichkeiten:

    Erweiterte Einstellungen für die Datendeduplizierung
    Weitere Informationen: Erweiterte Einstellungen für die Datendeduplizierung
    learn.microsoft.com


    Hier die wesentlichen Einstellungen für ein StrongBox Laufwerk:
    MinimumFileAgeDays : 1
    NoCompress : True
    OptimizeInUseFiles : True
    OptimizePartialFiles : True

    Solche riesen Datenmengen entstehen z.B. wenn Nutzer große Mengen an Mails verschieben, deren gelesen Status ändern oder ähnliches veranstalten.

    Bei uns im System reichen dafür schon prozentual recht kleine Änderungen um große Datenmengen anfallen zu lassen, da wir halt nen riesen Datenbestand von aktuell fast 3,7 TB haben. Seit die Deduplizierung auch auf die StrongBox Laufwerke ausgeweitet und dort angepasst konfiguriert wurde ist das aber praktisch kein Problem mehr.

  • lycra wir reden gerade nicht von einem NAS, sondern von deduplizierten Volumes auf einem Windows Server.

    Dedupliziert wird hier also das gesamte Volume, bzw. eben letztlich die darin gespeicherten Dateien, was in diesem Fall relevanter Weise die StrongBox Images sind.

    Wenn du auf Deinem NAS deduplizieren möchtest, dann musst Du Dich mit den Fähigkeiten Deines NAS das zu tun beschäftigen.

    Alternativ lässt Du Dein NAS Blockstorage bereitstellen und bindest diesen auf dem Windows Server beispielsweise via iSCSI oder Fiberchannel ein. Dann kannst Du auch dort die Deduplizierung im Windows Server mit dessen Bordmitteln steuern.

    Meine Strongboxen fressen hier Terrabytes und das erstellen eines Basisimage von aktuell halt 3,7 TB dauert trotz SSDs ein Wochenende, entsprechend werden die hier nicht alle Nase lang neu erzeugt, sondern länger für inkrementelle Backups genutzt.

    Für die Fragen von Ammermueller tut das allerdings grad wenig zur Sache, da ich bewusst nur die Deduplizierungsrate eines erst 20 Tage alten Images beschrieben habe.

    Gute Deduplizierungsraten erzielt man bei Strongboxen übrigens auch mit den oben von mir genannten Einstellungen nur dann wenn diese Einstellungen vor dem erstellen eines Images vorgenommen werden.
    Also Volume erstellen, Deduplizierung konfigurieren, dafür sorgen das auch ein Zeitplan zur Deduplikation mit ausreichend Zeit definiert ist. Erst dann das Volume zum erstellen eines neuen StrongBox Images verwenden und zuschauen wie dieses nach 24 Stunden langsam weniger Platz frisst als es das beim erstellen noch getan hat. so nach 3 Tagen sieht man dann deutliche Effekte. besonders deutlich werden die Effekte dann wenn Ereignisse eintreten welche in dem Fall welcher hier den Thread auslöste plötzlich zu deutlich größeren inkrementellen Backups führen als das rein durch die an dem Tag eingegangenen oder selbst versandten Mails zu erklären wäre, z.B. weil ein Nutzer große Mengen an Daten von einem Archiv in ein anderes verschoben, oder kopiert hat. In solchen Fällen glänzt die Deduplizierung dann halt richtig.

    Da ich einen David Server mit großer Datenbasis betreibe werden halt auch bei der nächtlichen automatischen Ablage gerne schon mal eine zweistellige Zahl an GB Daten in Ablagearchive verschoben und zack wächst auch meine StrongBox schnell mal um zweistellig GB an Daten.
    Das kann ohne Deduplikation schnell sehr viel physischen Platz auf den SSDs belegen, reduziert sich aber halt mittels Deduplikation schon drastisch.

    Auch bei der Datensicherung außerhalb des Servers macht sich das dann positiv bemerkbar, da Image basiert gesichert wird und diese Images dann halt entsprechend kleiner sind, als das Filebasiert oder eben ohne Deduplikation der Fall wäre.

  • Guten Morgen,

    also das erste neue stongbox-image wird nun am Freitag erstellt.
    Das Volume habe ich soweit ja vorkonfiguriert.

    muss/sollte man hier noch was anpassen in den Zeiten oder soll das dann so bleiben?


    Zeitplan
    Basis: Freitag - ab 17:45 Uhr
    Inkrementell: Samstag - Donnerstag - ab 19:00 Uhr

    Überschreiben nach 1 Tag

    Wir heben maximal 1-2 Images auf - Datenmenge einfach zu groß.


    Würde dass dann so passen ... aktuell sieht es so aus bei mir:
    0-0.stbox 465GB - Datenauslastung auf dem Laufwerk "nur" 200GB


    Edited once, last by ammermueller (January 22, 2025 at 9:58 AM).

  • wir reden gerade nicht von einem NAS, sondern von deduplizierten Volumes auf einem Windows Server.

    Ja daher ja meine Frage ob die Sicherungen oder eben David Ordner dedupliziert wurde ;)


    Hab aber nun von deinen Aussagen verstanden, dass deduplizieren bie NAS nicht geht und nur wenn man die Backups auf einem Windows Rechner/Server speichert es dort geht.

    Hast du dafür einen eigenen Server für Software Backups etc. ? Wir haben zur Sicherung nur eine alte NAS (DS918+) die nicht mal per Glasfaser angeschlossen ist. Ja schande über unser Haupt, ggf wird das mal verbessert in Zukunft aktuell reicht es für unsere Anwedungsfälle aber noch :D

    Meine Backups von 250gb größe bei Full sind ja nicht so groß ;)

  • Ja daher ja meine Frage ob die Sicherungen oder eben David Ordner dedupliziert wurde

    Die David Archivstruktur ist bei uns ebenfalls dedupliziert.
    Um die ging es hier im Thema aber ja aktuell nicht ;)
    Doch rein zur Befriedigung der Neugier ;) haben wir da stabil eine Deduplizierungsrate von 65%
    Ob man allerdings die Archivstruktur dedupliziert oder nicht ändert halt nichts daran wie groß Strongbox Images werden.

    Hab aber nun von deinen Aussagen verstanden, dass deduplizieren bie NAS nicht geht

    Das hab ich so nicht geschrieben, sondern das Deduplizierung beim NAS halt davon abhängt was das NAS kann.
    Manche NAS Systeme können deduplizieren, andere können es halt nicht.
    Wenn man mag kann man da aber halt gucken ob das NAS auch iSCSI kann und dann die Deduplikationsfunktionen des Windows Servers verwenden. Bei eher kleinen Datenvolumen kann das schon noch sinnvoll nutzbar sein.

    Hast du dafür einen eigenen Server für Software Backups etc. ?

    Ja, für Backups gibt es hier mehrere Server die sich ausschließlich um dieses Thema kümmern.
    Ist halt schon ein anderer Scale hier, wir produzieren halt täglich mindestens 2 stellig GB neue Daten, die langfristig gespeichert, gesichert und auch archiviert werden müssen.

    Am Ende muss halt jeder gucken was für ihn passt.

    Deduplizierung auf dem Windows Server kann aber halt auch denen helfen welche mit kleineren Setups fahren.
    Ich würde allerdings davon absehen Deduplizierung so zu verwenden das bei einem irgendwann eventuell mal nötigen Restore nicht ausreichend Speicher für eine nicht deduplizierte Wiederherstellung zur Verfügung steht.
    Ich nutze Deduplikation im David Archiv System daher vor allem um die SSDs zu schonen, die leben nämlich länger wenn große Bereiche unbenutzt bleiben und belegte Bereiche sich möglichst selten verändern. Entsprechen kann unser Server das komplette Volumen halt auch ohne Deduplikation halten und hat noch Raum für Wachstum. Die SSDs werden halt getauscht wenn sie zu klein werden und wandern dann in andere Server wo sie grad besser passen. Hier wird jedes Laufwerk aufgebraucht, aber keines erreicht das ende seiner Lebensdauer in dem Server für den es ursprünglich mal angeschafft wurde. Die meisten sterben nach Jahren dann ihren Tod in einem Client System, wo das nicht weh tut, sind bis dahin aber halt mehrfach durchgereicht worden. Dafür sind hier seit Jahren bis auf die langsamen Langzeit Backup Server alle Speichermedien nur noch SSDs, auch in den Clients.

    So, genug Off Topic, zurück zum Fragesteller ;)

  • Überschreiben nach 1 Tag

    Das erscheint mir etwas merkwürdig, wenn Du doch Vollbackups nur 1 mal die Woche machst und 2 Images aufhebst, da sehe ich dann eher überschreiben nach 7 Tagen (gerechnet ab letztem inkrementellem Backup im jeweiligen Set)

    Grundsätzlich bringt einem Deduplikation bei StrongBoxen halt die nötige Luft um Backups länger aufbewahren zu können.

    Ich würde in so einem Setup wohl nicht jede Woche ein neues Image anfangen, sondern nur 1 mal im Monat und davon 2 aufheben.

    Die Rechnung ist dabei simpel.
    Den größten Teil der Datenmenge eines StrongBox Images erzeugt das initiale Vollbackup am Anfang.
    Die inkrementellen Backups erzeugen nur noch wenig Zuwachs, die Deduplikation auf Dateisystemebene sorgt dafür das dieser Zuwachs tatsächlich nur aus neu hinzugekommenen oder veränderten Daten besteht und einfach nur innerhalb der Archive verschobene Daten sich kaum noch im Speicherbedarf der StrongBox Images auswirken.

    Denn das ist leider ein riesen Problem bei der StrongBox Sicherung des Tobit David Servers.
    Jede einfach nur innerhalb der Archivstruktur verschobene Mail mitsamt ihren Anhängen wird beim darauf folgenden inkrementellen Backup gesichert als ob sie neu im System wäre und das verursacht die oft unerklärlich großen täglichen Zuwächse der StrongBox Images.
    Würde Tobit das besser organisieren, die StrongBox Images intern deduplizieren und in solchen Fällen nur die veränderten Metadaten ins StrongBox Image schreiben wäre der ganze Thread hier gar nicht entstanden ;)

    Also, seltener Vollsicherungen, Deduplizierung, täglich inkrementelle Backups und dem Server täglich ausreichend Zeit zur Deduplizierung geben.

    Bei uns ist das Zeitfenster für die Deduplikation mit höchster Priorität so gelegt, das es Nachts immer etwa dann beginnt wenn die StrongBox Sicherung gerade fertig ist. Zusätzlich darf spät Nachmittags, wenn die meisten schon im Feierabend sind noch mal mit höchster Priorität dedupliziert werden, ansonsten darf der Server das rund um die Uhr it niedrigster Priorität tun.

    0-0.stbox 465GB - Datenauslastung auf dem Laufwerk "nur" 200GB

    Das ist doch auch schon mal ein schönes Ergebnis. Da kann man doch was mit dem dadurch gewonnenen Platz anfangen und Sicherungen länger aufbewahren :)

  • Vielen Dank für deine HIlfe. das hat mir alles schon sehr viel gebracht.

    Also das mit 1 Tag habe ich jetzt wieder höher gesetzt - ich werde das einfach mal beobachten wie es sich auf den Alltag nun auswirkt und kann mit den Parameter noch spielen.


    Die 3 Dedup-Tasks habe ich nun so geplant dass bis zum Vollbackup vom ganzen System alles durch sein sollte.
    Der erste Task läuft ja eh stündlich und die Bereinigungen dann mit Puffer vor dem Backup.


Participate now!

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