7
Veeam BuR Tape Backup, Bandwechsel aber zu früh!?!?
Mahlzeit und gesundes NEUES an alle IT-verrückten hier!
Ich bin gerade dabei Jahresbackups zu machen und nutze dazu Veeam B&R 12 (Community Edition) und schreibe die Backups von SMB Freigaben auf Tape (LTO-5). So banal, so gut.
Nun habe ich einen eigenartigen Effekt erlebt: Ein File-Backup, Active-Full mit ca. 2TB Daten von SMB-Freigabe to Tape läuft gut, aber er will bereits nach ca. 550GB ein neues Tape in das Einzellaufwerk eingelegt bekommen. Die Bänder haben doch aber 1,5TB Nettokapazität.
Ich bin irritiert, wie kommt denn sowas? Hat da jemand eine Idee?
Danke im Voraus
Kreuzberger
Ich bin gerade dabei Jahresbackups zu machen und nutze dazu Veeam B&R 12 (Community Edition) und schreibe die Backups von SMB Freigaben auf Tape (LTO-5). So banal, so gut.
Nun habe ich einen eigenartigen Effekt erlebt: Ein File-Backup, Active-Full mit ca. 2TB Daten von SMB-Freigabe to Tape läuft gut, aber er will bereits nach ca. 550GB ein neues Tape in das Einzellaufwerk eingelegt bekommen. Die Bänder haben doch aber 1,5TB Nettokapazität.
Ich bin irritiert, wie kommt denn sowas? Hat da jemand eine Idee?
Danke im Voraus
Kreuzberger
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670487
Url: https://administrator.de/forum/veeam-bur-tape-backup-bandwechsel-aber-zu-frueh-670487.html
Ausgedruckt am: 06.01.2025 um 19:01 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
Welches Laufwerk verwendest du? Hersteller, Modell, FW, Einstellungen, Jumper.
Welche Bänder verwendest du? Hersteller, Modell, evtl Einstellungen.
Kompromittierung Ein oder Ausgeschaltet?
Deine 1,5 TB sind die Native Kapazität oder die Kompromittierte?
OS ist was?
Das war schon ein Thema mit Streamer die angeblich 80 bzw. 100 MB können sollten, aber selten erreichten. Das Marheting war damals schon ein Hort für Lügengeschichten bzw. falsche Darstellung der Techn. Daten.
Gruss,
Peter
Welches Laufwerk verwendest du? Hersteller, Modell, FW, Einstellungen, Jumper.
Welche Bänder verwendest du? Hersteller, Modell, evtl Einstellungen.
Kompromittierung Ein oder Ausgeschaltet?
Deine 1,5 TB sind die Native Kapazität oder die Kompromittierte?
OS ist was?
Das war schon ein Thema mit Streamer die angeblich 80 bzw. 100 MB können sollten, aber selten erreichten. Das Marheting war damals schon ein Hort für Lügengeschichten bzw. falsche Darstellung der Techn. Daten.
Gruss,
Peter
Hallo Peter,
ich verwende LTO-5, demnach also 3TB Komprimiert, 1,5TB Netto.
Es ist ein Tandberg SAS, LTO-5. Kein Wechsler, sondern Einzellaufwrk.
In dem Fall sind es Fujifilm Bänder.
Windows Server 2022 Standard.
Ich denke es ist entweder
ein defektes Band, was ich so nicht glaube weil er es dann ja verweigert hätte
oder
Veeam will hier irgendwas trotz Active Full nicht überschreiben? Die Bänder/Jobs werden nicht mit Passwort geschützt und auch nicht Zeit-geschützt vor zu frühem überschreiben.
Kreuzberger
ich verwende LTO-5, demnach also 3TB Komprimiert, 1,5TB Netto.
Es ist ein Tandberg SAS, LTO-5. Kein Wechsler, sondern Einzellaufwrk.
In dem Fall sind es Fujifilm Bänder.
Windows Server 2022 Standard.
Ich denke es ist entweder
ein defektes Band, was ich so nicht glaube weil er es dann ja verweigert hätte
oder
Veeam will hier irgendwas trotz Active Full nicht überschreiben? Die Bänder/Jobs werden nicht mit Passwort geschützt und auch nicht Zeit-geschützt vor zu frühem überschreiben.
Kreuzberger
Moin,
War das Band im Vorfeld schonmal beschrieben worden?
Dann hat VEEAM vermutlich die neuen Daten hinten angefügt und nicht am Anfang des Bands begonnen…
Habt ihr eine Retention Policy auf dem MediaPool anliegen?
https://helpcenter.veeam.com/docs/backup/vsphere/tape_data_retention.htm ...
War das Band im Vorfeld schonmal beschrieben worden?
Dann hat VEEAM vermutlich die neuen Daten hinten angefügt und nicht am Anfang des Bands begonnen…
Habt ihr eine Retention Policy auf dem MediaPool anliegen?
https://helpcenter.veeam.com/docs/backup/vsphere/tape_data_retention.htm ...
1
@em-pie
Danke für den Tip.
Nach der Policy muss ich gucken. Das MediaPool besteht aus 2 Bändern. Das passt genau zur Größe des zu sichernden Volumes von 3TB. Es ist mit ca. 2TB gefüllt.
Kreuzberger
Danke für den Tip.
War das Band im Vorfeld schonmal beschrieben worden?
Aber JA! Das vorherige Backup des selben Jobs ist da drauf.Dann hat VEEAM vermutlich die neuen Daten hinten angefügt und nicht am Anfang des Bands begonnen…
Genau sowas hatte ich mir auch schon gedacht. Jedoch war/bin in verwundert, weil ich ja „ActiveFull“ Backup angestossen hatte (per Hand).Nach der Policy muss ich gucken. Das MediaPool besteht aus 2 Bändern. Das passt genau zur Größe des zu sichernden Volumes von 3TB. Es ist mit ca. 2TB gefüllt.
Kreuzberger
@em-pie
aaaaalso, ich hab mir die einstellungen im MediaPool angesehen. So sieht das da aus:
MediaPool
Tapes: 2 Tapes
MediaSet: Do not create .....
Retention: Do not protect......
Options: Enable parallel Processing, Process independent data sources
Parallel Processing ist eigentlich quatsch, weil es nur ein Tape-Laufwerk gibt. Es gibt keine Automatischen Jobs; alles Handbetrieb.
Ich kann also so nichts entdecken, was dieses Verhalten begründen könnte. Dennoch aber verdächtige ich auch, das er Backup-Daten vom Vorherigen Backup nicht überschrieben hat.
Kreuzberger
aaaaalso, ich hab mir die einstellungen im MediaPool angesehen. So sieht das da aus:
MediaPool
Tapes: 2 Tapes
MediaSet: Do not create .....
Retention: Do not protect......
Options: Enable parallel Processing, Process independent data sources
Parallel Processing ist eigentlich quatsch, weil es nur ein Tape-Laufwerk gibt. Es gibt keine Automatischen Jobs; alles Handbetrieb.
Ich kann also so nichts entdecken, was dieses Verhalten begründen könnte. Dennoch aber verdächtige ich auch, das er Backup-Daten vom Vorherigen Backup nicht überschrieben hat.
Kreuzberger
Zitat von @kreuzberger:
Dann hat VEEAM vermutlich die neuen Daten hinten angefügt und nicht am Anfang des Bands begonnen…
Genau sowas hatte ich mir auch schon gedacht. Jedoch war/bin in verwundert, weil ich ja „ActiveFull“ Backup angestossen hatte (per Hand).Da vertauscht du was, Active Full sagt nur das alle Daten gesichert werden sollen und nicht increment oder sonstwas. Das nichts damit zu tun das das Band von vorne verwendet werden soll.
Ich würde einfach das Band als "Mark as free" markieren, dann ist es für Veeam auch leer.
Auch können die 2TB trotzdem nicht auf ein band passen, Kompression ist zwar schön, aber nicht immer das was man so denkt
@Deepsys
Danke
Ich benutze die Kompression nicht oder nur selten, da das mit meist eh komprimierten datendicht funktioniert.
In dem Fall hatte Veeam bereits nach ca. 550GB einen Bandwechsel verlangt, obwohl ja auf ein band 1,5TB passen sollten. Das machte mich eben stutzig.
Ich denke auch dass man ggf. di Bänder zuvor als free markieren sollte.
Vermutung: er hat ja vor dem Schreiben die benötigte Datenmenge addiert und festgestellt, dass diese wohl auf das erste Band (Rest) und das zweite Band im Pool noch passen würde und so die Daten der vorhergehenden Sicherung (ca. 1TB) stehen gelassen. Vermutung: wären die Daten der vorhergehenden Sicherung deutlich größer gewesen wäre einfach alles auf dem ersten Band überschrieben worden. Könnte das sein?
Kreuzberger
Danke
Ich benutze die Kompression nicht oder nur selten, da das mit meist eh komprimierten datendicht funktioniert.
In dem Fall hatte Veeam bereits nach ca. 550GB einen Bandwechsel verlangt, obwohl ja auf ein band 1,5TB passen sollten. Das machte mich eben stutzig.
Ich denke auch dass man ggf. di Bänder zuvor als free markieren sollte.
Vermutung: er hat ja vor dem Schreiben die benötigte Datenmenge addiert und festgestellt, dass diese wohl auf das erste Band (Rest) und das zweite Band im Pool noch passen würde und so die Daten der vorhergehenden Sicherung (ca. 1TB) stehen gelassen. Vermutung: wären die Daten der vorhergehenden Sicherung deutlich größer gewesen wäre einfach alles auf dem ersten Band überschrieben worden. Könnte das sein?
Kreuzberger
