Sind denn da Dateien dabei die mehrfach vorkommen? von der Beschreibung her klingt es nicht so. Solange keine Daten mehrfach vorkommen kann eine Deduplizierung natürlich nichts deduplizieren.
Hallo, deine Dateien können vielleicth nicht dedupliziert werden: Audio und JPG sind schon optimierten. 
So ist es nicht gemeint.
Ich meine die Deduplizierung zwischen zwei unterschliedlichen Fullbackups innerhalb eines Jobs.
Fullbackup vom Datum A und Fullbackup vom Datum B haben stets die selbe größe.
Wenn ich dich richtig verstehe, möchtest du für mehrere Full Backups nur einmal den Speicherplatz verbrauchen. Das funktioniert nur mit ReFS im Windows und XFS im Linux Repository. Wo speicherst du denn deine Backups?
Hi,
Deduplizierung über Backup Files hinweg gibt es nicht.
Was wir etwas bringen wird sind sogenannte synthetische Full Backups in Kombination mit einen ReFS oder XFS Speicher. Hier wird das Feature Fast Block Cloning supported.
Dann spricht man von sogenantnen “Spaceless Synthetic Fulls” weil ein Full dank der Fast Block Cloning verpointerung nur etwa den Platz eines normalen Incrementals benötigt.
Grüße
Matze
Auch wenn ReFS das optimiert ablegt, wird die Datei immer gleich groß bleiben. Nur der tatsächliche Bedarf auf Disk wächst wenig.
Es gibt andere Backupsoftware oder Storage Appliances für Veeam, die speichern jedes Backup als synthetisches Full und rühmen sich dann mit super Dedup ratios. Das ist immer Toll für das Marketing und die Chefetage, weil die auf solche Zahlen stehen. Veeam zeigt aber immer ehrlich an, was tatsächlich los ist.
Wenn ich dich richtig verstehe, möchtest du für mehrere Full Backups nur einmal den Speicherplatz verbrauchen. Das funktioniert nur mit ReFS im Windows und XFS im Linux Repository. Wo speicherst du denn deine Backups?
Genau, es wird in eine SMB Freigabe auf einem Linuxserver gesichert.
Dann werde hier mir dies mal genauer ansehen müssen.
Danke euch.
Wenn ich dich richtig verstehe, möchtest du für mehrere Full Backups nur einmal den Speicherplatz verbrauchen. Das funktioniert nur mit ReFS im Windows und XFS im Linux Repository. Wo speicherst du denn deine Backups?
Genau, es wird in eine SMB Freigabe auf einem Linuxserver gesichert.
Dann werde hier mir dies mal genauer ansehen müssen.
Danke euch.
Das würde ich nicht machen.
Check mal ob die Disk im Linux XFS formatiert ist und ob reflink aktiviert ist. Falls du da nix weiter drauf hast, mit den Veeam empfohlenen Parametern formatieren.
Dann den Linux Server als Repository Server installieren (Veeam Transport Service) und dann kann Veeam nativ mit dem Host sprechen und die Backups schneller und optimiert ablegen.
So ist es nicht gemeint.
Ich meine die Deduplizierung zwischen zwei unterschliedlichen Fullbackups innerhalb eines Jobs.
Fullbackup vom Datum A und Fullbackup vom Datum B haben stets die selbe größe.
natürlich: die zwei Fullbackup müssen unabhängige sein. Oder, wenn eine Fullbackup gelöscht wird, die andere kaputt geht 
So ist es nicht gemeint.
Ich meine die Deduplizierung zwischen zwei unterschliedlichen Fullbackups innerhalb eines Jobs.
Fullbackup vom Datum A und Fullbackup vom Datum B haben stets die selbe größe.
natürlich: die zwei Fullbackup müssen unabhängige sein. Oder, wenn eine Fullbackup gelöscht wird, die andere kaputt geht
Was soll denn kaputt gehen? Wenn man Dedup hat und eine Datei davon löscht, löscht man ja wie immer nur die Pointer.
Wie schon mehrfach gesagt im Thread, Deduplizierung findet nur innerhalb eines Backup Laufs statt, also z.B. wenn mehrere Windows maschinen in einem Job sind, werden gleiche Datein dedupliziert.
Was du meinst ist das Block Cloning auf einem ReFS oder XFS formatierten Repository. Dort werden Blöcke eines Synthetic Fulls, die schon im Repository in einem Full Backup vorhanden sind, nur verlinkt und nicht ein zweites Mal auf Platte geschrieben.
Die Angaben zur Filegröße spiegeln das aber nicht wieder. Du siehst nur irgendwann, dass die Werte von benutzem Storage und die Menge an noch freiem Storage in einem Repository nicht der physischen Größe des Repositories entsprechen.
Und bei physischen Rechnern, muss du servergesteuerte Agenten einsetzen, um das Verfahren auszunutzen, wenn ich es richtig im Kopf habe...
So ist es nicht gemeint.
Ich meine die Deduplizierung zwischen zwei unterschliedlichen Fullbackups innerhalb eines Jobs.
Fullbackup vom Datum A und Fullbackup vom Datum B haben stets die selbe größe.
natürlich: die zwei Fullbackup müssen unabhängige sein. Oder, wenn eine Fullbackup gelöscht wird, die andere kaputt geht
Was soll denn kaputt gehen? Wenn man Dedup hat und eine Datei davon löscht, löscht man ja wie immer nur die Pointer.
alles verstanden, aber diese Deduplizierung kann nicht in der File Große gesehen verden.
Z.B. wenn du eine DadaDomain usw hast, man kann sie in der Dashboard der DataDomain sehen.
Wenn ich dich richtig verstehe, möchtest du für mehrere Full Backups nur einmal den Speicherplatz verbrauchen. Das funktioniert nur mit ReFS im Windows und XFS im Linux Repository. Wo speicherst du denn deine Backups?
Genau, es wird in eine SMB Freigabe auf einem Linuxserver gesichert.
Dann werde hier mir dies mal genauer ansehen müssen.
Danke euch.
Hallo @Ujo.
Da liegt der Fehler. Wenn Du das Repo als NAS Repo eingebunden hast, wird niemals Fast-Cloning verwendet werden. Hier produzierst Du auch beim Synthetic-Full immer unabhängige und maximal große VBKs.
Du musst das Linux-System als “richtiges” Repo mit DataMover einbinden. Also als Linuxserver mit DAS-Repo. Darunter muss dann das Volume für die Backups mit XFS (Reflink=1) formatiert sein. Sonst gibt es die @MatzeB angesprochenen “Spaceless Synthetic Fulls” nicht.
Siehe auch: Fast Clone - User Guide for VMware vSphere (veeam.com)
Dieses Verfahren ist auch keine “echte” Dedup. Ich spreche hier lieber von “verhinderter Duplizierung”, was faktisch sogar besser ist. Nachträglich kann man hier aber keine Luft mehr rauslassen. Die Magie muss immer exakt beim Synthetic-Full passieren.
