Veeam 7 auf Win 2012R2 als Backup-Repository mit Dedup?

[monster900]

Moin,
seit etwa 14 Tagen sichern wir unsere VM's mit Veeam 7.
Als Backupserver kommt ein physikalischer Server mit Windows 2012R2 zum Einsatz. Als Backuprepository steht ein lokales RAID-5 Volume mit 4,5TB (netto) im Server zur Verfügung. Die Backupdaten werden über einen LTO-5 Autoloader auf Band geschrieben.

Funktioniert auch soweit Alles absolut TOP und auch sehr performant! Allerdings stelle ich mir die Frage, ob sich mit aktivierter Deduplizierung auf dem Repository des Backupservers noch Speicherplatz gewinnen ließe.

Wir sichern mit Veeam rev. Inkrementel. Das Vollbackup aller VM's hat ca. 1,7 TB. Die inkrementellen Backups haben täglich ca. 130GB. So könnten wir ca. für 20 Tage Backups auf dem Repository vorhalten.
Würde eine Aktivierung der Deduplizierung auf dem Volume viel Speicherplatz bringen? Hat da jemand Erfahrungswerte mit Veeam und aktivierter Deduplizierung auf dem Repository?
Wie stark bricht die Performance ein, wenn ein Backup aus deduplizierten Daten wieder hergestellt werden muss (z.B. bei Deduplizierung aller Daten > 2 Tage)?
Werden beim Schreiben der Backups auf Band die Daten in 'deduplizierter' Form auf das Band geschrieben oder findet während der Bandsicherung wieder eine Wandlung in 'normale' Form statt?
Wir wirkt sich so etwas auf die Performance der Bandsicherung aus?

Ich habe zu dem Thema zwar einige Beiträge in diversen Blogs gefunden, aber dort war leider nichts über praktische Erfahrungen zu finden.

Gruß
Dirk

[omicronont]

Hallo,

ich habe vor etwa drei Monaten genau das ausprobiert (Veeam 7.0.0.871, etwa 25 VMs, Vollbackup etwa 4,3 TB, Sicherungsziel Windows Server 2012 -nicht 2012 R2!). Veeam eingestellt als einmal pro Woche Vollsicherung, Rest inkrementel (nicht reverse inkremental). Restore-Points 12. Die Veeam-eigene Deduplizierung hatte ich ausgeschaltet und die Kompressions-Rate auf "Dedupe-Friendly" eingestellt.

Genau habe ich es nicht mehr im Kopf. Ja, es gab eine ganz erhebliche Reduzierung des Platzbedarfs im Repository - ich weiß aber nicht mehr, ob das 50% oder so waren. Es war auf jeden Fall "deutlich".

Allerdings hatte ich nach etwa drei Wochen problemlosen Betrieb das Problem, dass Dateien im Backup-Repository nicht mehr lesbar waren, als ich sie per robocopy weggeschrieben hatte - Windows meldete CRC-Fehler beim Kopiervorgang. Ein chkdsk /f des Laufwerks ergab nichts. Die entsprechenden Dateien mussten aus der Datensicherung wiederherstellt werden.
Das Ganze passierte innerhalb von zwei Wochen zweimal, und dann habe ich die Deduplizierung auf der Partition des Backup-Repository wieder deaktiviert und lebe damit, dass der Platzbedarf deutlich größer ist. Die Veeam-Einstellungen habe ich wieder auf "Veeam-Dedupe aktiviert" und die Kompression auf "Extreme" eingestellt.

Seitdem (mindestens zwei Monate her) habe ich keinen einzigen CRC-Fehler bei Dateien des Backup-Repository mehr gehabt.

Ob sich die Laufzeit des Backup-Jobs bei dem Experimentieren verändert hatte, weiß ich nicht mehr - auf jeden Fall nicht so, dass ich es bemerkt hätte.

Gruß,

Knut

[monster900]

Danke Knut,
wurden die Daten beim Kopieren mit robocopy als Dedup-Daten kopiert oder findet beim kopieren eine Wiederherstellung der Urdatenmenge ohne Dedup statt?
Wie hat sich das auf die Performance des robocopy-Jobs ausgewirkt?

Evtl. findest Du hier die Lösungsmöglichkeit Deines Problems mit den fehlerhaften Backupdaten.
http://pipitone.co/2014/06/26/configure-windows-server-2012-r2-deduplication-and-veeam-backup-replication-7-for-vmware/

Zitat "Due to the fact that the built in Windows Deduplication role has scheduled tasks that trigger optimization, garbage collection, and scrubbing jobs, the files can get heavily fragmented. Microsoft also recommends not having files on a Deduplicated volume that are over 1TB in size. Microsoft has provided a fix for this in Server 2012 R2, however in order to take advantage of the fix, you’ll need to format the Deduplicated volume using the /L switch to support having larger files on a volume with Deduplication enabled. This switch will eliminate the file system limitation error."

Gruß
Dirk

[omicronont]

Danke für den Link. Den kannte ich noch nicht. Ja, zwangsläufig entstehen Dateien größer als 1 TB im Backup Repository (Vollsicherung), insofern bewegt man sich da offensichtlich auf dünnem Eis (siehe Dein Zitat).

Sagen wir es so: Mir ist es deutlich lieber, ich habe ein "verläßliches" Backup-Repository als eins, an dem ich mit vielen Tricks eine Festplatten-Erweiterung eingespart habe - und ich unter Umständen im Katastrophen-Fall in Platzprobleme hineinrenne - ganz zu schweigen von dem Fall, dass ich erst dann merke, dass die Backup-Dateien nicht funktionsfähig sind.
Insofern habe ich meine Experimente in dem Bereich eingestellt und einfach den Plattenplatz vergrößert..

Beim Kopieren mit Robocopy haben die Dateien auf dem Ziel-Volume automatisch wieder die Original-Größe - das kann ja auch anders gar nicht sein. Ob sich die Laufzeit von robocopy verlängert hat, kann ich nicht mehr sagen sagen - ich hatte es mir nicht aufgeschrieben. Auf jeden Fall gab es keine "deutliche" Veränderung.

Gruß,

Knut

[monster900]

Ja,
das sehe ich ähnlich. Ein Backup ohne ein funktionierendes Restore taugt nichts!

Im Augenblick kommen wir super mit dem Backupspeicher hin. Mal sehen, ob ich im nächsten Jahr mein Backup-Storage im 2. Brandabschnitt genehmigt bekomme. Dann fällt das tägliche Bandsichern weg.

Gruß
Dirk

[irix]

Ich gehe mal davon aus das ein Microsoft Dedup keine Daten zertoert aber...... MS Dedup ist eher fuer kleine Dateien welche sich nicht aendern bzw. nicht geloescht werden. Das ist aber je nach Veeam Sicherungsmethode ganz anders und somit nicht Dedup Friendly in der Art wie MS das macht.

Wenn du auf einem Dedup Speicher etwas loescht dann bekommst du keinen freien Speicher zurueck. Da muss erst die Cleanup/Garbage laufen. Das heist man braucht Reserveplatz.

Gruss
Joerg

[omicronont]

Als Ergänzung: Die bei mir fehlerhaften Dateien waren alle deutlich kleiner als 1 TB (es waren die Incremental-Backup-Dateien, nicht die Fullbackups).

Dedup habe ich auf anderen Volumes, die mit dem Veeam-Backup-Repository überhaupt nichts zu tun haben, problemlos seit einigen Monaten am Laufen - mit der gleichen Windows-Version (Server 2012, nicht R2).

Dayworker hatte es ja mal ganz richtig auf den Punkt gebracht:

Falls ein Block/Chunk kaputt geht, betrifft es auch alle anderen darauf referenzierten

(aus: http://vmware-forum.de/viewtopic.php?p=159070#159070).


Gruß,

Knut