3
Symantec Backup Exec Vers.12.5 - Sicherung endet mit Fehlern bzw. wird abgebrochen
Domäne mit W2K8-Servern (Dell2950), Dell Tape-Library TL 2000 (LTO-Bänder, umgelabelte IBM-TL), Thomas Krenn Server mit iSCSI-Laufwerken als File-Server
Moin zusammen,
kaum das eine Problem gelöst, schon schlägt das nächste ein.
Wir hängen an einem RZ und haben den Serverbetrieb komplett als "Full-Service" an das RZ übertragen. Dies Kollegen dort schauen remote auf unsere Server und arbeiten daran, wenn es notwendig sein sollte. Soweit die Theorie.
Leider läuft seit mehreren Wochen die Datensicherung nicht mehr sauber. BE bricht die Sicherungsläufe mit den Fehlercodes
- E0008821 bei inkrementell Backup-to-Disk, bei Full Backup-to-Disk
- E000846B bei inkrementell Backup-to-Disk,
- E0008488 bei inkrementell Backup-to-Disk,
- E0008507 bei inkrementell Backup-to-Disk
ab.
Montag bis Donnerstag läuft ein inkrementelles Backup-to-Disk. Am Freitag ein Full Backup-To-Disk, welches anschließend auf per Backup-to-Tape auf Band gespeichert wird.
Jeden letzten Samstag im Monat soll ein "Monatsband" erstellt werden, welches dann als Drittsicherung in einen anderen Brandabschnit verlagert wird.
Das ist der Soll-Zustand. Ist-Zustand sieht laut Log-Einträgen leider katastrophal aus. Ich muß davon ausgehen, daß derzeit keine Datensicherung verfügbar ist.
Bevor jetzt das Geschrei losgeht: Da hättest Du aber früher was machen müssen - hab ich. Leider sind mir sicherungstechnisch die Hände gebunden, ich darf da nicht dran, sonst steigt das RZ aus dem "Full-Service"-Vertrag aus. Ich darf nur Calls/Tickets aufgeben und die Fehler melden. Anyway.
Aus den Fehlercodes habe ich u.a. schon mal entnommen, daß es evtl. Probleme mit den Volumen-Schattenkopien bei einem Exchange Server geben kann. OK. Exchange ist im Einsatz, wäre also eine Möglichkeit.
Eine andere Ursache könnte laut Fehlerbeschreibung eine nicht erhaltene Antwort auf eine Anfrage während der Sicherung sein. Auch das könnte ich mir als Grund vorstellen.
Nach meinen Erkenntnissen hat die Fehlerproblematik angefangen, als das Sicherungsband (LTO, 400 GB unkromprimiert, 800 GB komprimiert) einen Füllstand von 396,x GB aufwies. Rechne ich jetzt ein wenig Overhead für Dateiinformationen hinzu, bin ich bei den unkomprimierten 400 GB. Da die Sicherung zunächst (komprimiert?) auf Platte geschrieben wird, kann es mit den 400 GB schon hinkommen. Meine Vermutung liegt nun da, daß während der Sicherung das Band voll wird und kein Nachfolgeband angefordert werden kann, da die Response fehlt. Dies würde auch erklären, warum bei der Monatssicherung die Sicherung eigentlich durchläuft, das Band aber nicht ausgeworfen werden kann, da der IO-Slot zu dem Zeitpunkt, an dem das Band ausgeworfen werden soll, noch belegt ist.
Jetz meine Fragen an die BE-Experten:
Wenn die Kapazität des Bandes erschöpft ist, sollte sich die Tape-Library das nächste als frei gekennzeichnete Sicherungsband holen und dort mit der Sicherung weitermachen. Geschieht dies automatisch, oder muß in den Sicherungsjob eine Art Autoresponse eingebaut werden, welche die etwaige Anfrage nach einem Folgeband beantwortet?
Was passiert in dem Fall mit der Plattensicherung? Ich würde vermuten, daß dort solange Daten gesichert werden, bis die Kapazität der Platte erschöpft ist. Und dann? Platte wechseln fällt ja wohl aus. Ergo müßte da doch ein Mechanismaus greifen, der bei Erreichen eines Schwellenwertes eine Meldung absetzt und dadurch manuelles Eingreifen erforderlich macht, oder?
Ich möchte möglichst bald wieder auf eine funktionierende Datensicherung zurückgreifen können, habt ihr noch weitere Tipps für mich, die ich an das RZ weitergeben kann?
Gruß J
chem
Moin zusammen,
kaum das eine Problem gelöst, schon schlägt das nächste ein.
Wir hängen an einem RZ und haben den Serverbetrieb komplett als "Full-Service" an das RZ übertragen. Dies Kollegen dort schauen remote auf unsere Server und arbeiten daran, wenn es notwendig sein sollte. Soweit die Theorie.
Leider läuft seit mehreren Wochen die Datensicherung nicht mehr sauber. BE bricht die Sicherungsläufe mit den Fehlercodes
- E0008821 bei inkrementell Backup-to-Disk, bei Full Backup-to-Disk
- E000846B bei inkrementell Backup-to-Disk,
- E0008488 bei inkrementell Backup-to-Disk,
- E0008507 bei inkrementell Backup-to-Disk
ab.
Montag bis Donnerstag läuft ein inkrementelles Backup-to-Disk. Am Freitag ein Full Backup-To-Disk, welches anschließend auf per Backup-to-Tape auf Band gespeichert wird.
Jeden letzten Samstag im Monat soll ein "Monatsband" erstellt werden, welches dann als Drittsicherung in einen anderen Brandabschnit verlagert wird.
Das ist der Soll-Zustand. Ist-Zustand sieht laut Log-Einträgen leider katastrophal aus. Ich muß davon ausgehen, daß derzeit keine Datensicherung verfügbar ist.
Bevor jetzt das Geschrei losgeht: Da hättest Du aber früher was machen müssen - hab ich. Leider sind mir sicherungstechnisch die Hände gebunden, ich darf da nicht dran, sonst steigt das RZ aus dem "Full-Service"-Vertrag aus. Ich darf nur Calls/Tickets aufgeben und die Fehler melden. Anyway.
Aus den Fehlercodes habe ich u.a. schon mal entnommen, daß es evtl. Probleme mit den Volumen-Schattenkopien bei einem Exchange Server geben kann. OK. Exchange ist im Einsatz, wäre also eine Möglichkeit.
Eine andere Ursache könnte laut Fehlerbeschreibung eine nicht erhaltene Antwort auf eine Anfrage während der Sicherung sein. Auch das könnte ich mir als Grund vorstellen.
Nach meinen Erkenntnissen hat die Fehlerproblematik angefangen, als das Sicherungsband (LTO, 400 GB unkromprimiert, 800 GB komprimiert) einen Füllstand von 396,x GB aufwies. Rechne ich jetzt ein wenig Overhead für Dateiinformationen hinzu, bin ich bei den unkomprimierten 400 GB. Da die Sicherung zunächst (komprimiert?) auf Platte geschrieben wird, kann es mit den 400 GB schon hinkommen. Meine Vermutung liegt nun da, daß während der Sicherung das Band voll wird und kein Nachfolgeband angefordert werden kann, da die Response fehlt. Dies würde auch erklären, warum bei der Monatssicherung die Sicherung eigentlich durchläuft, das Band aber nicht ausgeworfen werden kann, da der IO-Slot zu dem Zeitpunkt, an dem das Band ausgeworfen werden soll, noch belegt ist.
Jetz meine Fragen an die BE-Experten:
Wenn die Kapazität des Bandes erschöpft ist, sollte sich die Tape-Library das nächste als frei gekennzeichnete Sicherungsband holen und dort mit der Sicherung weitermachen. Geschieht dies automatisch, oder muß in den Sicherungsjob eine Art Autoresponse eingebaut werden, welche die etwaige Anfrage nach einem Folgeband beantwortet?
Was passiert in dem Fall mit der Plattensicherung? Ich würde vermuten, daß dort solange Daten gesichert werden, bis die Kapazität der Platte erschöpft ist. Und dann? Platte wechseln fällt ja wohl aus. Ergo müßte da doch ein Mechanismaus greifen, der bei Erreichen eines Schwellenwertes eine Meldung absetzt und dadurch manuelles Eingreifen erforderlich macht, oder?
Ich möchte möglichst bald wieder auf eine funktionierende Datensicherung zurückgreifen können, habt ihr noch weitere Tipps für mich, die ich an das RZ weitergeben kann?
Gruß J
chem
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: 205689
Url: https://administrator.de/contentid/205689
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
vorab, ist BE 12.5 überhaupt für Server 2008 (R2?)?
Das ist ja schon was älter .....
BE versucht immer das Backup auszuführen und holt sich dazu auch schon mal gerne Bänder aus Medienpools aus denen das Admin das nicht wollte. Ergo, wenn noch was irgendwo frei ist, wird das benutzt.
Und Autoreponse habe ich noch nie gehört bei BE, und ich mach das schon ein paar Jahre
Du kannst für Backup--Disk-Ordner einstellen, ab wann die Aufträge eingestellt werden.
EDIT: Wo taucht denn der Fehler überhaupt auf, noch beim Diskbackup oder beim Tape?
Wenn ich mal nach deinem Fehler suche, komme ich eher darauf das da evtl. die Anbindung nicht stimmt.
Wo liegen denn die Disks, lokal oder NAS oder SAN?
Wie ist der Loader angeschlossen?
Lief das Ganze überhaupt schon mal?
VG
deepsys
vorab, ist BE 12.5 überhaupt für Server 2008 (R2?)?
Das ist ja schon was älter .....
Zitat von @Jochem:
Wenn die Kapazität des Bandes erschöpft ist, sollte sich die Tape-Library das nächste als frei gekennzeichnete
Sicherungsband holen und dort mit der Sicherung weitermachen. Geschiehrt dies automatisch, oder muß in den Sicherungsjob
eine Art Autoresponse eingebaut werden, welche die etwaige Anfrage nach einem Folgeband beantwortet?
Das geht 100% automatisch, aber du musst auch Bänder haben die BE beschreiben darf.Wenn die Kapazität des Bandes erschöpft ist, sollte sich die Tape-Library das nächste als frei gekennzeichnete
Sicherungsband holen und dort mit der Sicherung weitermachen. Geschiehrt dies automatisch, oder muß in den Sicherungsjob
eine Art Autoresponse eingebaut werden, welche die etwaige Anfrage nach einem Folgeband beantwortet?
BE versucht immer das Backup auszuführen und holt sich dazu auch schon mal gerne Bänder aus Medienpools aus denen das Admin das nicht wollte. Ergo, wenn noch was irgendwo frei ist, wird das benutzt.
Und Autoreponse habe ich noch nie gehört bei BE, und ich mach das schon ein paar Jahre
Was passiert in dem Fall mit der Plattensicherung? Ich würde vermuten, daß dort solange Daten gesichert werden, bis die
Kapazität der Platte erschöpft ist. Und dann? Platte wechseln fällt ja wohl aus. Ergo müßte da doch ein
Mechanismaus greifen, der bei Erreichen eines Schwellenwertes eine Meldung absetzt und dadurch manuelles Eingreifen erforderlich
macht, oder?
Wieso dann nun Platte, ich denke wir sind bei Band?Kapazität der Platte erschöpft ist. Und dann? Platte wechseln fällt ja wohl aus. Ergo müßte da doch ein
Mechanismaus greifen, der bei Erreichen eines Schwellenwertes eine Meldung absetzt und dadurch manuelles Eingreifen erforderlich
macht, oder?
Du kannst für Backup--Disk-Ordner einstellen, ab wann die Aufträge eingestellt werden.
EDIT: Wo taucht denn der Fehler überhaupt auf, noch beim Diskbackup oder beim Tape?
Ich möchte möglichst bald wieder auf eine funktionierende Datensicherung zurückgreifen können, habt ihr noch
weitere Tipps für mich, die ich an das RZ weitergeben kann?
Ja, warum zum Geier die Admins das bei einem Full-Service nicht gebacken bekommen...weitere Tipps für mich, die ich an das RZ weitergeben kann?
Wenn ich mal nach deinem Fehler suche, komme ich eher darauf das da evtl. die Anbindung nicht stimmt.
Wo liegen denn die Disks, lokal oder NAS oder SAN?
Wie ist der Loader angeschlossen?
Lief das Ganze überhaupt schon mal?
VG
deepsys
Moin,
Soviel zu den Fehlermeldungen, wo sie auftreten und wo gesichert wird. Der TK-Server steht lokal neben den anderen Servern. Der Loader ist über iSCSI am TK-Server angeschlossen.
Und JA, das Ganze lief schon mal. Wir haben 2009 die Serverlandschaft neu aufgebaut übers RZ und zu dem Zeitpunkt wurde auch die Datensicherung eingerichtet. Es fehlte zwar die Bereitstellung des "Monatsbandes", aber das wurde im Laufe 2011 nachgeholt. Von Mai bis September habe ich entsprechende Bänder erhalten. Zu dem Zeitpunkt, wo meiner Meinung nach das Band "übergelaufen" ist, haben die Probleme mit der Sicherung angefangen. Zunächst hat nur sporadisch die eine oder andere Tagessicherung Fehler ausgeworfen, mittlerweile laufen alle B2D-Sicherungen auf den Hammer. B2T läuft so lala, da der vorherige B2D-Job mit Fehlern endete.
Gruß J chem
Montag bis Donnerstag läuft ein inkrementelles Backup-to-Disk. Am Freitag ein Full Backup-To-Disk, welches
anschließend auf Tape gespeichert wird.
anschließend auf Tape gespeichert wird.
- E0008821 bei inkrementell Backup-to-Disk, bei Full Backup-to-Disk
- E000846B bei inkrementell Backup-to-Disk,
- E0008488 bei inkrementell Backup-to-Disk,
- E0008507 bei inkrementell Backup-to-Disk
- E000846B bei inkrementell Backup-to-Disk,
- E0008488 bei inkrementell Backup-to-Disk,
- E0008507 bei inkrementell Backup-to-Disk
Thomas Krenn Server mit iSCSI-Laufwerken als File-Server
Soviel zu den Fehlermeldungen, wo sie auftreten und wo gesichert wird. Der TK-Server steht lokal neben den anderen Servern. Der Loader ist über iSCSI am TK-Server angeschlossen.
Und JA, das Ganze lief schon mal. Wir haben 2009 die Serverlandschaft neu aufgebaut übers RZ und zu dem Zeitpunkt wurde auch die Datensicherung eingerichtet. Es fehlte zwar die Bereitstellung des "Monatsbandes", aber das wurde im Laufe 2011 nachgeholt. Von Mai bis September habe ich entsprechende Bänder erhalten. Zu dem Zeitpunkt, wo meiner Meinung nach das Band "übergelaufen" ist, haben die Probleme mit der Sicherung angefangen. Zunächst hat nur sporadisch die eine oder andere Tagessicherung Fehler ausgeworfen, mittlerweile laufen alle B2D-Sicherungen auf den Hammer. B2T läuft so lala, da der vorherige B2D-Job mit Fehlern endete.
Gruß J
chem
Hi,
Ansonsten den Support von Symantec anrufen, wenn du einen Wartungsvertrag hast.
VG
Deepsys
Zitat von @Jochem:
Soviel zu den Fehlermeldungen, wo sie auftreten und wo gesichert wird. Der TK-Server steht lokal neben den anderen Servern. Der
Loader ist über iSCSI am TK-Server angeschlossen.
Und warum suchst du dann bitte auf vollen LTO-Bändern, wenn es schon auf Disk scheitert?Soviel zu den Fehlermeldungen, wo sie auftreten und wo gesichert wird. Der TK-Server steht lokal neben den anderen Servern. Der
Loader ist über iSCSI am TK-Server angeschlossen.
Und JA, das Ganze lief schon mal.
Dann würde ich an deiner Stelle mal alle Fehlermeldungen in Symantecs Supportdatenbank eingeben und mal alle Lösung durcharbeiten.Ansonsten den Support von Symantec anrufen, wenn du einen Wartungsvertrag hast.
VG
Deepsys
