Veeam BuR, Tape-Backup bricht ab
Mahlzeit Digitalfreunde,
ich bin hier etwas ratlos, aber ggf. hat da jemand ein Idee.
Da ist ein Server 2012 (ohne R2) als reiner Fileserver, also eine Primitive Datentonne mit 6 x 2TB HDD.
Da ist ein frisch aufgesetzter Server 2022 mit Veeam B&R 12 mit einem LTO5 Single Laufwerk, der auf anderen zu sichernden Servern bisher reibungslos funktioniert und Daten auf Tape sichert.
Bei dem o. g. Server (FS2-Mediathek) bockt er aber. Die Administrator-Zugangsdaten sind korrekt und nochmals verifiziert. Damit fängt er auch Backup-Jobs an, bei diesem aber stoppt er aber sogleich, und für mich unerklärlich mit „Zugriff verweigert“.
Ein Weiterer Job wurde nach eineinhalb voll geschriebenen Bändern nach 1,7TB gesichertem Datenvolumen ohne Fehlermeldung einfach angehalten. Sprich: Das zweite Band wurde eingelegt, mit ca. 300GB beschrieben und dann einfach nicht weiter beschrieben. Der Job wurde nicht gestoppt. Er wartete also nicht auf ein neues Band, das lag ja schon drin und wurde angefangen zu beschreiben.
„Transport“ ist installiert.
Server 2012 (ohne R2) wir als geringste Version von Veeam B&R 12 laut Veeam unterstützt.
Zugangsdaten sind korrekt.
Netzwerk funktioniert (1GB)
Netzauflösung (DNS) funktioniert.
Irgendwas ist hier mit den Zugriffsrechten falsch, obwohl ich die Administrator-Zugriffsrechte korrekt eingetragen habe.
Hat da jemand eine Idee?
Danke
Kreuzberger
ich bin hier etwas ratlos, aber ggf. hat da jemand ein Idee.
Da ist ein Server 2012 (ohne R2) als reiner Fileserver, also eine Primitive Datentonne mit 6 x 2TB HDD.
Da ist ein frisch aufgesetzter Server 2022 mit Veeam B&R 12 mit einem LTO5 Single Laufwerk, der auf anderen zu sichernden Servern bisher reibungslos funktioniert und Daten auf Tape sichert.
Bei dem o. g. Server (FS2-Mediathek) bockt er aber. Die Administrator-Zugangsdaten sind korrekt und nochmals verifiziert. Damit fängt er auch Backup-Jobs an, bei diesem aber stoppt er aber sogleich, und für mich unerklärlich mit „Zugriff verweigert“.
Ein Weiterer Job wurde nach eineinhalb voll geschriebenen Bändern nach 1,7TB gesichertem Datenvolumen ohne Fehlermeldung einfach angehalten. Sprich: Das zweite Band wurde eingelegt, mit ca. 300GB beschrieben und dann einfach nicht weiter beschrieben. Der Job wurde nicht gestoppt. Er wartete also nicht auf ein neues Band, das lag ja schon drin und wurde angefangen zu beschreiben.
„Transport“ ist installiert.
Server 2012 (ohne R2) wir als geringste Version von Veeam B&R 12 laut Veeam unterstützt.
Zugangsdaten sind korrekt.
Netzwerk funktioniert (1GB)
Netzauflösung (DNS) funktioniert.
Irgendwas ist hier mit den Zugriffsrechten falsch, obwohl ich die Administrator-Zugriffsrechte korrekt eingetragen habe.
Hat da jemand eine Idee?
Danke
Kreuzberger
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 9591839610
Url: https://administrator.de/forum/veeam-bur-tape-backup-bricht-ab-9591839610.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
40 Kommentare
Neuester Kommentar
Ich hatte vor ~3 Wochen ein merkwürdiges Problem mit Veeam 12 direkt auf 2012 R2, er konnte sich nicht mehr am vCenter authentifizieren. Da 2012 R2 ja fast nie Updates bekommt macht die Kiste auch fast nie Neustarts, die Backups liefen aber jede Nacht über lange Zeit und plötzlich kein Auth mehr und nachvollziehen konnte ich das auch nicht. Ein Neustart hat dann geholfen, solche Probleme kenne ich eigentlich nicht bei Veeam.
Du versuchst die ntuser.dat zu sichern, diese ist jedoch immer (meistens) offen. Vermutlich bekommst du weniger oder andere Fehler, wenn der Administrator abgemeldet ist.
Damit die Bandsicherung immer erfolgreich ist sollte folgende Strategie gefahren werden:
Der Backupserver soll genug Festplatten haben um die Server zu auf Platte zu sichern.
Die Bandsicherung sollte dann die fertig gesicherten Dateien/ den Sicherungsordner auf Band ablegen, keine direkte Sicherung von den Servern auf Band.
Damit die Bandsicherung immer erfolgreich ist sollte folgende Strategie gefahren werden:
Der Backupserver soll genug Festplatten haben um die Server zu auf Platte zu sichern.
Die Bandsicherung sollte dann die fertig gesicherten Dateien/ den Sicherungsordner auf Band ablegen, keine direkte Sicherung von den Servern auf Band.
@kreuzberger
Kurze Frage: Wie wird die Datensicherung angestossen? Wie Scheduler vom VEAAM, oder vom Windows?
Könnte man die Sicherung nicht via Benutzer SYSTEM anstarten?
Gruss Penny.
Kurze Frage: Wie wird die Datensicherung angestossen? Wie Scheduler vom VEAAM, oder vom Windows?
Könnte man die Sicherung nicht via Benutzer SYSTEM anstarten?
Gruss Penny.
Zu viel Gefrickel!
Wie gesagt sind die Dateien gesperrt. Nicht umsonst gibt es ja Schattenkopieren oder ganze Images. VM hatte wir damals Tape als 2. Lokation. Die VM Sicherung lag schon vor - wurde nur dann weggeschrieben.
Auf Dateiebene mit entspechenden Agent arbeiten! Entweder von Veeam, oder auch jedes andere Tool. Vorher halt die Daten bündeln und hin senden. TAR - der Name kommt ja nicht von ungefähr.
So ähnlich sollte man immer noch das Konzept beibehalten.
C separat sichern. Veeam, Acronis, Windows Backup... Irgendwas, was ein Image im laufenden Betrieb erstellen kann.
Du hast ja auch nicht jeden Tag eine komplette Änderung der Nutzdaten. Da sollte auf jedenfall das Backup Programm vorher bündeln und nur inkrementell oder differentiell sichern.
Dein Konzept ist falsch, bzw. nicht ganz rund.
Wie gesagt sind die Dateien gesperrt. Nicht umsonst gibt es ja Schattenkopieren oder ganze Images. VM hatte wir damals Tape als 2. Lokation. Die VM Sicherung lag schon vor - wurde nur dann weggeschrieben.
Auf Dateiebene mit entspechenden Agent arbeiten! Entweder von Veeam, oder auch jedes andere Tool. Vorher halt die Daten bündeln und hin senden. TAR - der Name kommt ja nicht von ungefähr.
So ähnlich sollte man immer noch das Konzept beibehalten.
C separat sichern. Veeam, Acronis, Windows Backup... Irgendwas, was ein Image im laufenden Betrieb erstellen kann.
Du hast ja auch nicht jeden Tag eine komplette Änderung der Nutzdaten. Da sollte auf jedenfall das Backup Programm vorher bündeln und nur inkrementell oder differentiell sichern.
Dein Konzept ist falsch, bzw. nicht ganz rund.
@Crusher:
Ich glaube, daß es an der Community Edition liegt. Bei der Vollversion sollte das Problem nicht auftreten.
Genauso wie bei syncsort BEX (jetzt Catalogic DPX), IBM Tivoli Storage Manager (jetzt IBM Storage-Protect), HP Data Protector und weitere Backupprodukten.
Gruss Penny.
Ich glaube, daß es an der Community Edition liegt. Bei der Vollversion sollte das Problem nicht auftreten.
Genauso wie bei syncsort BEX (jetzt Catalogic DPX), IBM Tivoli Storage Manager (jetzt IBM Storage-Protect), HP Data Protector und weitere Backupprodukten.
Gruss Penny.
C: muss nicht - immer - sein.
Du solltest C auch sichern, dann aber nicht via File Bakup. Bei der Menge an Dateien würd ich es separat betrachten und es in 2 Jobs aufteilen. 1x Dateien 1x Image von C
Da es keine VM ist, dann auch an Boot-Medium + Treiber denken ... RAID Treiber, falls C auch auf einen RAID liegt etc.
Du solltest C auch sichern, dann aber nicht via File Bakup. Bei der Menge an Dateien würd ich es separat betrachten und es in 2 Jobs aufteilen. 1x Dateien 1x Image von C
Da es keine VM ist, dann auch an Boot-Medium + Treiber denken ... RAID Treiber, falls C auch auf einen RAID liegt etc.
Also nochmal langsam: Backup Programm helfen beim Komprimieren in dem sie komprimieren und auch meist deduplizieren. Beides braucht Zeit. Dann haben wir noch sowas wie Application Aware. Kennen wir ja von Datenbanken etc.
Sichern und Schreiben auf einer HD geht bei Image nicht. Bei Dateien kommt doch alles in eine vmdk als Container. Wenn der Platz ausreicht kann man damit doch bequem alles zusammenfassen und komprimieren lassen. Auf der HD eben.
Dateizugriff, Virenscanner und auch ggf. fehlerhafte Dateien muss man klären. Kopie von vielen kleinen Dateien dauert ja ohnehin länger. All sowas könnte die Transferrate herabsetzen.
Wenn du einen oder mehrere Task und damit vmdk erstellst kann man gegensteuern. Ggf. Dienste beenden, oder bei der 2. Sicherung Inrkementell/ Differentiell vorgehen und somit eh Dauer und Größe stark reduzieren.
Beim zurücksichern muss ja sonst auch erst das Band gelesen, ggf. indizier tun die Dateien kopiert werden. Liegen aber z.B. 1 TB vmdk vor, so wird dich sciherlich rasch - je anch Performance des LTO-Laufwerkes und des Zieles - kopiert werden. Klar muss man die im 2. Schrnitt dann auch wieder zurückscihern, um an die Dateien zu kommen.
ABER du kansnt die VMDK doch browsen und statt 1TB nur die wichtigsten Daten dann auf den Virenbefallenen Server zurück spielen. Ist vom Handling praktischer.
Erst bündeln, dann aufs Band. Ggf. Ausschlüsse definieren von unnötigen Ordnern die ggf. auch noch im Zugriff sind und Backup da hängen lassen.
Bei meinen Vollbackups mit Acronis kann ich die exportierten tibx Dateien auch einfach öffnen und komme unter Windows und Linux an die Dateien ran.
Gut, das ist ein Image. Aber du kannst es doch 1:1 auf die Dateien übertragen. 1-3 große "Bunker" - vmdk Dateien - und gut ist. Der tägliche Zuwachs hält sich doch in Grenzen.
Da du eh dann Plattenplatz für die im ersten Schritt lokale Sicherung auf der HD brauchst gibst du gedanklich gleich ein paar GB hzinzu für die kommenden Diff/ Ink Sicherungen. Hast dann 1 Depot auf HD und 1 Depto auf Band. Wegen immutable Backup sogar gut so.
So oder so denke ich lohnt es sich den ersten Schritt auf HD zu vollziehen. Ist kein Platz da, würde ich über den Kauf und Einbau einer 2. HD nachdenken. SSD meinetwegen - wegen der Performance. Vorhaltezeit der Daten kannst du da eh vergessen, da du ja noch auf Band sicherst. Zudem wird jede gute HD nicht nach 3 Tagen die Daten ins Nirvana schiießen ....
Komprimierung und Deudup auf einer lokale SSD als Zwischenbackup ist doch durch aus legitim. Klar wen der Server abbrennt oder Virus zu schlägt sind die weg. Ist aber ja egal - du hast ja noch dein Band! Es macht nur sicherlich deutlich merhr Spass.
Sichern und Schreiben auf einer HD geht bei Image nicht. Bei Dateien kommt doch alles in eine vmdk als Container. Wenn der Platz ausreicht kann man damit doch bequem alles zusammenfassen und komprimieren lassen. Auf der HD eben.
Dateizugriff, Virenscanner und auch ggf. fehlerhafte Dateien muss man klären. Kopie von vielen kleinen Dateien dauert ja ohnehin länger. All sowas könnte die Transferrate herabsetzen.
Wenn du einen oder mehrere Task und damit vmdk erstellst kann man gegensteuern. Ggf. Dienste beenden, oder bei der 2. Sicherung Inrkementell/ Differentiell vorgehen und somit eh Dauer und Größe stark reduzieren.
Beim zurücksichern muss ja sonst auch erst das Band gelesen, ggf. indizier tun die Dateien kopiert werden. Liegen aber z.B. 1 TB vmdk vor, so wird dich sciherlich rasch - je anch Performance des LTO-Laufwerkes und des Zieles - kopiert werden. Klar muss man die im 2. Schrnitt dann auch wieder zurückscihern, um an die Dateien zu kommen.
ABER du kansnt die VMDK doch browsen und statt 1TB nur die wichtigsten Daten dann auf den Virenbefallenen Server zurück spielen. Ist vom Handling praktischer.
Erst bündeln, dann aufs Band. Ggf. Ausschlüsse definieren von unnötigen Ordnern die ggf. auch noch im Zugriff sind und Backup da hängen lassen.
Bei meinen Vollbackups mit Acronis kann ich die exportierten tibx Dateien auch einfach öffnen und komme unter Windows und Linux an die Dateien ran.
Gut, das ist ein Image. Aber du kannst es doch 1:1 auf die Dateien übertragen. 1-3 große "Bunker" - vmdk Dateien - und gut ist. Der tägliche Zuwachs hält sich doch in Grenzen.
Da du eh dann Plattenplatz für die im ersten Schritt lokale Sicherung auf der HD brauchst gibst du gedanklich gleich ein paar GB hzinzu für die kommenden Diff/ Ink Sicherungen. Hast dann 1 Depot auf HD und 1 Depto auf Band. Wegen immutable Backup sogar gut so.
So oder so denke ich lohnt es sich den ersten Schritt auf HD zu vollziehen. Ist kein Platz da, würde ich über den Kauf und Einbau einer 2. HD nachdenken. SSD meinetwegen - wegen der Performance. Vorhaltezeit der Daten kannst du da eh vergessen, da du ja noch auf Band sicherst. Zudem wird jede gute HD nicht nach 3 Tagen die Daten ins Nirvana schiießen ....
Komprimierung und Deudup auf einer lokale SSD als Zwischenbackup ist doch durch aus legitim. Klar wen der Server abbrennt oder Virus zu schlägt sind die weg. Ist aber ja egal - du hast ja noch dein Band! Es macht nur sicherlich deutlich merhr Spass.
Haben überwiegend MySQL. Postgres bei Zammad. Letzterer sichert die DB + Files. Immer 2 Archive.
Also sind es nur Postgres SQL Backups? Was für eine Art? Dump? Oder Continuous Archiving and Point-in-Time Recovery (PITR)?
Bei Datenbanken wollen wir ja eh ungern Tage oder Wochen zurück gehen. Wann wird Full-Backup gemacht? Wie groß sind die Datenbanken? Sind die zig tausend Dateien nur Postgres Backup?
Braucht man wirklich alle Backups? Retention? Sind das bereinigte Daten? Also mittels Retention alte Backups schon gelöscht?
SQL Backup hab ich vestanden. Nur sind das so viele Einzeldateien.
Also sind es nur Postgres SQL Backups? Was für eine Art? Dump? Oder Continuous Archiving and Point-in-Time Recovery (PITR)?
Bei Datenbanken wollen wir ja eh ungern Tage oder Wochen zurück gehen. Wann wird Full-Backup gemacht? Wie groß sind die Datenbanken? Sind die zig tausend Dateien nur Postgres Backup?
Braucht man wirklich alle Backups? Retention? Sind das bereinigte Daten? Also mittels Retention alte Backups schon gelöscht?
SQL Backup hab ich vestanden. Nur sind das so viele Einzeldateien.
es ist die Community-Version, da geht diese art von Sicherung nicht.
Welche Art von Sicherung meinst du?Mit der Community Edition darfst du mit einer Veeam Installation bis zu 3 physische Server sichern. Veeam installiert dir einen Agent auf dem zu sichernden Server und macht eine Schattenkopie auch aller offenen Dateien. Er säubert dir auch die Logs von offenen Datenbanken, sodaß du den gesamten Rechner gesichert bekommst.
Und wenn du mehr als 3 physische Server oder 10VMs sichern möchtest, darfst du mehrere Community Editions auf verschiedene Server installieren, die sich z.B. selbst sichern und alles auf ein Share auf den Backup legen, du hast dann nur keine zentrale Verwaltung. Und dieses Share kannst du ganz normal auf Band sichern.
Ich will mich nicht ins Debugging einmischen, konnte gar nicht alles verfolgen. Aber wäre vielleicht ein Lizenzproblem denkbar? In meiner Kauflizenz sind 500 GB SMB Share Sicherung enthalten. Als ich versucht habe, mehr zu sichern, gab es entsprechende Meldungen. Wie das in der Community Edition ist, weiß ich nicht. Gibt es eventuell ein Datenlimit bei der Bandsicherung? Hängt es immer bei der Verarbeitung bei etwa der gleichen Datenmenge?
Zitat von @ukulele-7:
Aber wäre vielleicht ein Lizenzproblem denkbar? In meiner Kauflizenz sind 500 GB SMB Share Sicherung enthalten.
Deckt sich mit dem Artikel hier im letzten Post:Aber wäre vielleicht ein Lizenzproblem denkbar? In meiner Kauflizenz sind 500 GB SMB Share Sicherung enthalten.
https://forums.veeam.com/tape-f29/community-edition-tape-backup-t84505.h ...
It consumes one of the free licenses for every 500GB source data. Therefore you can write 5TB to Tape if no other workloads are protected by the backup server.
Wie man das nun als Backup auf Tape bekommt weiss ich jetzt leider aber nicht.
Ganz normal, Backup anlegen, Ordner auswählen, den du eben gezeigt hast, fertig.Das sind lokale Dateien auf dem Backupserver und diese sollte er ohne Schwierigkeiten auf Tape bringen können.
Grundsätzlich wäre mir das Verfahren erst auf die Platte und dann aufs Tape so gesehen zu umständlich und langwierig.
So ist es halt von Veeam als Best Practice vorgesehen.Zitat von @kreuzberger:
Wenn ich diese Backup-Datei so wie sie ist auf Bänder sichere, habe ich dann die Möglichkeit, aus dem Band einzelne Dateien direkt zurückzusichern, oder muss ich dann die Gesamte Backup-Datei erst zurücksichern um daraus wieder einzelne Dateien zu extrahieren?
Ja du hast alle Möglichkeiten mit dem Tape, die du sonst auch hast. Zusätzlich halt das Disk Backup.Wenn ich diese Backup-Datei so wie sie ist auf Bänder sichere, habe ich dann die Möglichkeit, aus dem Band einzelne Dateien direkt zurückzusichern, oder muss ich dann die Gesamte Backup-Datei erst zurücksichern um daraus wieder einzelne Dateien zu extrahieren?
Diese „best Practice“ ist bekloppt. (sorry)
Seit gefühlt Jahrhunderten sichere ich direkt Daten to Tape, das habe ich ganz früher schon mit Retrospect auf DAT-Band so gemacht, was immer gut funktionierte.
Das war eigentlich auch früher schon Standard bei allen Backup to Tape Produkten, die ich so eingesetzt habe (Symantec, Acronis, etc.) in allen Umgebungen, die ich betreut habe. Gut, hier im Haus wollte ich das auch so, grade weil ich Rücksicherungen von Disk schneller machen kann als von Tape (mein Tape liegt extern). Ich habe es daher nie anders versucht.Seit gefühlt Jahrhunderten sichere ich direkt Daten to Tape, das habe ich ganz früher schon mit Retrospect auf DAT-Band so gemacht, was immer gut funktionierte.
Ich würde daher sagen es ist die gewöhnliche Art, ich denke eine direkte Tape Sicherung dürfte i.d.R. auch nicht scheitern. Warum sie das jetzt auf einmal tut ist mir ein Rätsel. Es gab bei Veeam auch Probleme, bei denen eine Neuanlage des Jobs geholfen hat.
Also ich habe im Backup to Disk-Job unter Secondary Target einen Backup to Tape-Job. Das kann man da anlegen oder direkt als Job so wie bei dir, dann entspricht es einem "Backups to taoe..."
Ich muss gestehen ich sichere fast nie einzelne Dateien vom Tape zurück. Ich kann das grade nicht testen weil das Tape läuft... Ich würde aber zu 99% sagen das müsste gehen.
Ich muss gestehen ich sichere fast nie einzelne Dateien vom Tape zurück. Ich kann das grade nicht testen weil das Tape läuft... Ich würde aber zu 99% sagen das müsste gehen.
Wenn ich diese Backup-Datei so wie sie ist auf Bänder sichere, habe ich dann die Möglichkeit,
aus dem Band einzelne Dateien direkt zurückzusichern, oder muss ich dann die Gesamte Backup-Datei erst
zurücksichern um daraus wieder einzelne Dateien zu extrahieren?
Diese „best Practice“ ist bekloppt. (sorry)
aus dem Band einzelne Dateien direkt zurückzusichern, oder muss ich dann die Gesamte Backup-Datei erst
zurücksichern um daraus wieder einzelne Dateien zu extrahieren?
Diese „best Practice“ ist bekloppt. (sorry)
Warum vom Band? DAS ist bekkloppt, sorry.
Du machst ein Full Backup und danach täglich incrementelle Backups, alles nur auf die Platte, aufs Band spielst du dann z.B. wöchentlich um sie aus der Brandschutzzone zu tragen. Einzelne Dateien holst du aus dem Plattenbackup zurück, nicht vom Band.
Hinweis: du siehst die konsumierten Lizenzen unter Burger Menü License.
Abrechnung in Workloads - max 10 Stck.
1 x Workload = 500 GB
10 x Workloads = 5 TB
Du hast max 5 TB drin. Die Lizenzen kann man da auch freigeben. Normal müsste aber die Fehlermeldung dann anders ausschauen. Die Lizenzen werden normal dynamisch bei 1. Benutzung abgezogen. Sollte Backup nicht anhalten - so lange man nicht übre 10 hinaus kommt.
Achtung: Testspielerien können auch 1 Lizenz gekostet haben. Ggf. dann über den License Manager wieder Lizenzen freigeben.
Hab noch die alte Veam Version 11 hier. Du kannst den Veaam Server als Fileserver in Veeam einrichten und laufen lassen. Sichert dann sich selber auf File Ebene. Hast du das gemacht?
Backup Repository Typ Windows. Da wird dann alles ja automatisch hinzugefügt. Hast statt Share dann deine normalen Laufwerne + Ordner.
Abrechnung in Workloads - max 10 Stck.
1 x Workload = 500 GB
10 x Workloads = 5 TB
Du hast max 5 TB drin. Die Lizenzen kann man da auch freigeben. Normal müsste aber die Fehlermeldung dann anders ausschauen. Die Lizenzen werden normal dynamisch bei 1. Benutzung abgezogen. Sollte Backup nicht anhalten - so lange man nicht übre 10 hinaus kommt.
Achtung: Testspielerien können auch 1 Lizenz gekostet haben. Ggf. dann über den License Manager wieder Lizenzen freigeben.
Hab noch die alte Veam Version 11 hier. Du kannst den Veaam Server als Fileserver in Veeam einrichten und laufen lassen. Sichert dann sich selber auf File Ebene. Hast du das gemacht?
Backup Repository Typ Windows. Da wird dann alles ja automatisch hinzugefügt. Hast statt Share dann deine normalen Laufwerne + Ordner.