HBS 3 und übersprungene Dateien

  • Hallo,


    ich sichere mein System mittels cloudberry auf ein TS-873A mit Raid 6 und 55 TB WD Platten drin.

    Das ganze macht wöchentlich ein Vollbackup und dann täglich ein inkrementelles.

    Das ganze klappt auch und läuft fix durch.

    Ich wollte nun das TS-873A wiederum sichern auf ein TS-453A mit Raid 5 und 10 TB Platten.

    Leider bekomme ich es nicht hin, da der Backupjob immer abbricht, mit dem Hinweis, dass zu viele Dateien übersprungen wurden.

    Ich habe in dem HBS Job jetzt schon die Grenze auf 1000 gestellt, mehr geht ja nicht, aber ich bin mir nicht sicher, ob ich da jetzt nicht ein inkonsistentes Backup erzeuge.

    Problem ist einfach, dass cloudberry mit dem Sichern auf das TS-873A wesentlich schneller ist, als ich das von 873 auf 473 bekomme.

    Das inkrementelle Backup bei cloudberry läuft vielleicht eine Stunde, das Vollbackup ungefähr 5, der Job von 873 auf 473 mittels HBS 3 bei 4 TB läuft 2 Tage.

    In der Zwischenzeit hat sich halt auf der 873 schon wieder einiges verändert und dann meckert HBS, weil er die Dateien nicht finden kann.

    Vielleicht ist mein Ansatz auch Quatsch, aber macht den HBS nicht einen Snapshot und sichert den dann?

    Die Konfigurationsmöglichkeiten bei HBS sind ja eher bescheiden.

    Wäre über jede Hilfe dankbar, ich kämpfe hier schon eine Woche.

  • Liefere mal Infos zu den Job Parametern die du verwendest.

    Da kann man schon ein paar Sachen einstellen.


    Hört sich nach eine default Job mit QuDedup an.

  • Ja, ist ziemlich default.


    Also, der Job läuft wöchentlich einmal

    Versionsverwaltung ist komplett aus

    QuDedup ist aktiviert

    Datenintegrität prüfe ich (vorerst) nicht

    Es sind keine Filter aktiv

    Bei den Richtlinien ist TPC-BBR aktiviert

    Nur aktualisierte Dateien sichern ist aktiv

    Gelöschte Dateien vom Ziel entfernen nach 180 Tagen

    Verstreute Dateien erkennen ist aktiv und ausgegraut

    Keinen Snapshot aufnehmen ist aktiv uns ausgegraut

    Einmal editiert, zuletzt von AS-N ()

  • Du sicherst also mit QuDedup aktiv und erstellst kein Snapshot.

    Punkt 1:

    Geht massiv auf die Performace, steht auch dabei. Bitte bauen sie SSDs ein und dann schreiben wir diese beim Backup sinnlos in die TBW, nein danke!


    Punkt 2:

    Wenn sich dann Daten ändern und der Job noch läuft, Bingo Fehler wegen geänderter Dateien.

  • Verstehe ich es richtig, dass das Backup auf das x73 noch läuft, während vom x73 auf das x53 gesichert werden soll?

    Dann muss der Job vom x73 auf das x53 später bzw. im Anschluss starten, sonst werden die Dateien ja noch geändert und es kommt zu dem Problem. Snapshot könnte das beheben, aber der wird ja nicht erstellt und offensichtlich auch nicht erstellt werden können, da es vermutlich ein statisches Volume ist.

    Prinzipiell wäre ein Snapshot hier aber auch nicht zielführend, da Du sonst ja nie weißt, welche Dateien genau im Backup landen. Die könnten genau so gut defekt sein, weil der snapshot während der Änderung halt nur eine "halbfertige" Datei aufnimmt die dann im Backup landet. Daher würde ich das unbedingt zeitversetzt machen.

  • Ja, statisches Volumen.

    ich hätte aber noch zwei 1TB SSD drin, die derzeit den Cache beschleunigen sollen.

    Das bringt aber meiner Ansicht nach eh nichts, könnte ich die für den Snapshot nehmen?


    Und ja, da x73 auf x53 eben 2 Tage braucht, läuft da der tägliche Backupjob von Cloudberry natürlich zweimal zwischendrin.

    Soll ich den dann an den beiden Tagen, an denen qnap sichert pausieren?

    Das ist dann aber auch doof.

  • Das bringt nix mit dem Cache.


    Du musst auf einen Speicherpool umstellen, also das Raid dafür komplett killen, inkl. aller Freigaben.

    Tauscht du nicht die HDs, bleibt die Grundkonfiguration inkl. Gruppen und User erhalten.


    Dann kannst du Snapshots einsetzen, damit immer ein konsistentes Backup weg sichern und dann den Job ohne QuDedup neu anlegen.

    Dann rennt der je nach Änderung Minuten bis paar Stunden, je nach Datenmenge.

  • Also das SSD Raid killen?

    Und die beiden dann als Speicherpool umstellen?


    Die HDDs fasse ich nicht mehr an, das sind 30 TB drauf.

  • Das TS-873A ist das Quellsystem, für Snapshots im Job brauchst du einen Speicherpool.


    Kannst auch versuchen ob der Job mit genug Zeitabstand ohne QuDedup sauber läuft.

  • Ja, aber würden da die beiden SSD auf dem 873A gehen, als Speicherpool, oder müssen die ganzen Daten in einem Pool liegen?

    Also muss ich die 8 HDDs in einen Speicherpool wandeln?

    Dann müsste ich ja aber die ganzen Daten wieder auslagern und den Pool erstellen und dann wieder zurückspielen.

    Wie soll ich das machen?

    Sorry, aber ich verstehe das noch nicht ganz.

    Gibt es einen Dienstleister, der mir das einrichten kann?

  • Nein die SSDs reichen nicht, da die Daten auf dem Raid 6 liegen muss hier der Pool eingerichtet werden.


    Also erstmal den Job ohne QuDedup neu erstellen, Backup fahren.

    Wenn du dann wieder Probleme bekommst, weil sich die Jobs auch mit genügend Abstand überschneiden, dann muss die Pool Geschichte her.


    Das dauert dann, weil du alle Daten auslagern musst, das Raid löschen, neu Einrichten, dann baue es erstmal den Pool auf. Wenn das fertig ist kannst du hier das Tick Volume drauf packen, das dauert dann nur Minuten.

    Dann aber musst du alle Daten zurück spielen.

    50TB bei GBit sind etwa 5-6 Tage.

  • Ich versuche jetzt erstmal ohne QuDedup. Aber die geschätzte Backupdauer ist 14 Tage.

    Vielleicht gehts ja schneller.

    Sollte ja auch nur beim ersten Mal so lange dauern, oder?

  • Ja das erste mal ist ein Fullbackup, dann sichert er nur noch das neue.

    Je nach Speed Quelle/Ziel dauert es halt.

  • OK, danke.

    Dann versuche ich jetzt so mein Glück und wenn es nicht geht, dann den Speicherpool.

    Aber da melde ich mich nochmal, nicht dass ich wieder was falsch einrichte. ;)

    Schönes Wochenende!