HyperBackup Backup Datenbank klonen?

[Heidi]

Guten Tag zusammen,

das NAS wird per Hyperbackup in die Ferne auf eine Ziel-NAS gesichert. Dort liegen also die zerschnipselten *.hbk-Blobs Folders. Nun möchten wir uns ein weiteres Backup-Ziel NAS an einem 3. Ort anschaffen und dorthin ebenfalls sichern. Nun könnte man einfach jungfräulich beginnen das 2. Backup anzulegen und wachsen lassen. Da hätte man dann aber die Historie (Versionierung) nicht mehr.

Gibt es eine Möglichkeit das vorhandene Backup zu klonen? Ich stelle mir vor, dass man die gesamte *.hbk File (=Folder) rüber-kopiert und dann mit einem neuen HyperBackup-Task "neu verknüpft". Beim Anlegen eines solchen Tasks ist dem Task ja schließlich egal wie und woher die *.hbk kommt. Hauptsache header+Blobs sind vorhanden und passen zusammen.

Hat damit schon jemand Erfahrung?

 

[plang.pl]

Ich würde es so versuchen, wie du gesagt hast: Kopieren des kompletten Hyper Backup Folders und neu verknüpfen. Spricht eigentlich nix dagegen

 

[Heidi]

Ja, am besten ist es ich versuche es mal im Vorfeld mit einem Dummy-Backup. Dann kann ich auch gleich mal ausprobieren, was passiert, wenn man einzelne Blob-Dateien "verliert". Mal schauen, was das backup daraus macht. Ich berichte....

 

[Heidi]

So, ich bin nun schlauer.

Ich habe ein Testbackup erzeugt und die komplette *.hbk File an einen anderen Ort kopiert. Durch das Erstellen eines neuen Sicherungs-Tasks mittels "neu Verknüpfen" funktioniert das wie geschmiert. Das Backup ist mit allen Vorgängerversionen wieder verfügbar. Ein Klon also. Ich habe dann in dem alten und dem neuen Backup Dinge verändert und ausgeführt. Saubere Trennung, keine Verknüpfungsüberschneidung der beiden Backups.
Damit ist die primärfrage des Threads beantwortet.

Ich habe weiter getestet. Man kann den *.hbk Ordner auch nach Belieben umnennen.

Löscht man eine *.index oder *.bucket file aus dem Pool-Ordner, dann bekommt man bei der nächsten Integritätsprüfung den Hinweis, dass das Backup Fehlerhaft ist und kann sich die von der Chunk-File betroffenen Dateien (und Einzelversionen) ausgeben lassen.
Das sieht dann so aus:

Backup task was unable to run due to errors found at the backup destination.
The following files were found broken in the latest integrity check and cannot be restored.
There may be other broken files which were not detected this time.
If you have further questions, please contact Synology support.

Broken file(s):
Version: 2023-08-09 13:54:53+0200, shared folder: testbackup
  File    353699636    2022-02-02 10:49:11  stat Zugtest_M33.modfem
Version: 2023-08-09 13:52:30+0200, shared folder: testbackup
  File    353699636    2022-02-02 10:49:11  stat Zugtest_M33.modfem
Version: 2023-08-09 13:31:19+0200, shared folder: testbackup
  File    353699636    2022-02-02 10:49:11  stat Zugtest_M33.modfem

Im HyperBackup Explorer wird das dann ausgegraut dargestellt. So weiß man immerhin über den Schaden gut Bescheid und kann ggf. aus einem weiteren Backup recovern. Der Backuptask ist in diesem Fall jedoch korrupt und kann nicht wieder belebt werden. Read-only.

Wird jedoch "zu viel" aus dem Haupt-hbk-Ordner gelöscht ist das Backup nicht wieder herstellbar.

Damit finde ich das recht robust gelöst. Wenn das Backup nun noch im BTRFS und Raid1/6 liegt, dann kann fast nichts mehr schief gehen.

 

[metalworker]

Schöner Test von dir .

Ich mag HB auch sehr ,
wenn jetzt noch einführt das HB vom Clienst keine Versionen löschen kann .Dann wäres so gut wie perfekt