5
Backupexec 10d Disk to Tape Problem
Hallo, ich versuche meine erstem Schritte mit Backupexec zu machen. Irgendwie will es aber nicht so richtig klappen.
Ich habe einen Auftrag erstellt der einen Server sichern soll und in den lokalen "Backup to Disk" Ordner ablegt. Dann habe ich einen Auftrag erstellt der alle *.bfk aus dem Folder auf Band sichert und danach löscht. Nun habe ich versucht eine Datei zu recovern, dies schlägt aber fehl weil ja das Medium aus dem Ordner weg ist. Dann habe ich was gelesen von "duplizieren von Mediensätzen". also habe ich einen solchen Auftrag erstellt. und zu testzwecken mit beiden Aufträgen verknüpft. Aber irgendwie scheint da immernoch was flasch zu sein, da ich die Datei immernoch nicht recovern kann.
Kenn sich jemand damit aus und kann mir das mal erklären.
Gruß Mike
Ich habe einen Auftrag erstellt der einen Server sichern soll und in den lokalen "Backup to Disk" Ordner ablegt. Dann habe ich einen Auftrag erstellt der alle *.bfk aus dem Folder auf Band sichert und danach löscht. Nun habe ich versucht eine Datei zu recovern, dies schlägt aber fehl weil ja das Medium aus dem Ordner weg ist. Dann habe ich was gelesen von "duplizieren von Mediensätzen". also habe ich einen solchen Auftrag erstellt. und zu testzwecken mit beiden Aufträgen verknüpft. Aber irgendwie scheint da immernoch was flasch zu sein, da ich die Datei immernoch nicht recovern kann.
Kenn sich jemand damit aus und kann mir das mal erklären.
Gruß Mike
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 38250
Url: https://administrator.de/contentid/38250
Printed on: April 19, 2024 at 00:04 o'clock
5 Comments
Latest comment
Hallo Mike,
wenn Du die *.bfk-Dateien löscht kann Du auch keine Datei recovern. Ich mache zwar keine Backup2Disk2Tape-Sicherungen, aber ich meine (hoffentlich stimmt das jetzt), dass man dann nicht direkt vom Band eine Datei recovern kann. Die eigentliche Sicherung ist die *.bkf-Datei, das Tape ist nur eine "Auslagerung". Das Löschen der *.bkf-Dateien solltest die Veritas (über die Schutzfristen der Mediensätze) überlassen.
Meine Meinung, lasse mich gerne belehren.
Gruß Bolle97
wenn Du die *.bfk-Dateien löscht kann Du auch keine Datei recovern. Ich mache zwar keine Backup2Disk2Tape-Sicherungen, aber ich meine (hoffentlich stimmt das jetzt), dass man dann nicht direkt vom Band eine Datei recovern kann. Die eigentliche Sicherung ist die *.bkf-Datei, das Tape ist nur eine "Auslagerung". Das Löschen der *.bkf-Dateien solltest die Veritas (über die Schutzfristen der Mediensätze) überlassen.
Meine Meinung, lasse mich gerne belehren.
Gruß Bolle97
Das Problem ist erstmal gelöst. Ich habe jetzt einen Auftrag erstellt, der den Server auf die Disk sichert, dann kommt ein Anschlußauftrag "Duplizieren von Mediensätzen". Dann kann ich auch direkt vom Band recovern da die Infos entsprechend angepasst wurden.
Nun ein neues Problem.
Ich sichere merehre Server in einem Rutsch auf Disk. Dabei werden 100 GB geschrieben. Beim Duplizieren werden zwar die Files auf Band geschrieben aber danach nicht gelöscht. Beim nächsten Backup werden zwar nur 80 GB neue Daten geschrieben, aber die von den 100 GB vom Vortag wurden ja nur 80x 1GB *.bkf Files Überschrieben. Somit sind noch 20 alte da und beim duplizieren werden dann 100 GB aufs Band geschrieben. Bietet Backupexec dafür eine Lösung oder muss ich dafür eine Batch laufen lassen um jeden Tag den Ordner zu leeren?
Gruß Mike
Ich sichere merehre Server in einem Rutsch auf Disk. Dabei werden 100 GB geschrieben. Beim Duplizieren werden zwar die Files auf Band geschrieben aber danach nicht gelöscht. Beim nächsten Backup werden zwar nur 80 GB neue Daten geschrieben, aber die von den 100 GB vom Vortag wurden ja nur 80x 1GB *.bkf Files Überschrieben. Somit sind noch 20 alte da und beim duplizieren werden dann 100 GB aufs Band geschrieben. Bietet Backupexec dafür eine Lösung oder muss ich dafür eine Batch laufen lassen um jeden Tag den Ordner zu leeren?
Gruß Mike
Somit sind noch 20 alte da und beim
duplizieren werden dann 100 GB aufs Band
geschrieben. Bietet Backupexec dafür
eine Lösung oder muss ich dafür
eine Batch laufen lassen um jeden Tag den
Ordner zu leeren?
Gruß Mike
duplizieren werden dann 100 GB aufs Band
geschrieben. Bietet Backupexec dafür
eine Lösung oder muss ich dafür
eine Batch laufen lassen um jeden Tag den
Ordner zu leeren?
Gruß Mike
Ja Backup Exec bietet ne Lösung, ich habs bei mir wie folgt beschrieben gelöst.
Unter Geräte werden deine Backup to Disk Dateien angezeigt.
Dort gehst du mit der rechten Maustaste auf den Backup to Disk Ordner und sagst Eigenschaften im dann auftauchenden Fenster Konfiguration.
Da sagst du dann max. Größe von Backup to Disk Dateien meinetwegen 200GB. Diese Zahl muss einfach nur größer sein als deine größte Sicherung. Veritas legt dann nur eine einzige Datei an, wenn du für diese Datei einen eigenen Mediensatz erstellst kannst du in diesem Mediensatz den Anhängezeitraum und Überschreibschutz auf 1 Stunde legen. Veritas überschreibt dann am nächsten Tag die Datei, auf dem Band wird dann auch nur die neuen Daten dupliziert.
Jetzt hast du aber noch ein Problem, in deinem momentanen Backup to Disk Ordner stehen noch 99 andere Dateien, da du diesen nur als Temporäre Sicherung nimmst lösche am besten alles und erstelle es neu, geht denke ich am schnellsten. Unter Medien werden zwar noch die alten Dateien angezeigt die kannst du aber erst in den Mediensatz "Ausrangierte Medien" verschieben und daraufhin dort löschen.
Falls du was nicht verstanden hast oder ich was zu undeutlich erklärt habe frag einfach nochmal nach.
Hallo,
Danke das hat alles mal geklappt, aber nun ein neues Problem. In dem Ordner sind auf einmal 3 *.bkf und das Duplizieren schlagt mit Fehler http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml?EvtID=V-79 ...
fehl.
Danke das hat alles mal geklappt, aber nun ein neues Problem. In dem Ordner sind auf einmal 3 *.bkf und das Duplizieren schlagt mit Fehler http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml?EvtID=V-79 ...
fehl.
