4
Backup Exec 15 beschreibt neue Temporäre Bänder, obwohl noch Bänder im Medienpool Platz haben
Hallo,
folgendes habe ich bei Backups festgestellt.
Ich sichere Daten eines Netapp-Filers per BE15 auf Band. Das System sichert ohne Probleme holt sich aber scheinbar wenn bei einer Sicherung ein Band während dem Backup voll wird ein Band aus dem Pool der Temporären Medien, obwohl noch genügend Bänder mit freiem Platz im Pool des Backups sind, welches die Sicherung durchführt.
Das macht mich verrückt, denn besser wäre es wenn das Backup erst einmal alles beschreibt, dass frei ist auf den Bändern im eigentlichen Pool.
Kennt das Phänomen jemand?
Ich habe mal die Settings des Pools angehangen.
danke und Gruß
Gmeurb
folgendes habe ich bei Backups festgestellt.
Ich sichere Daten eines Netapp-Filers per BE15 auf Band. Das System sichert ohne Probleme holt sich aber scheinbar wenn bei einer Sicherung ein Band während dem Backup voll wird ein Band aus dem Pool der Temporären Medien, obwohl noch genügend Bänder mit freiem Platz im Pool des Backups sind, welches die Sicherung durchführt.
Das macht mich verrückt, denn besser wäre es wenn das Backup erst einmal alles beschreibt, dass frei ist auf den Bändern im eigentlichen Pool.
Kennt das Phänomen jemand?
Ich habe mal die Settings des Pools angehangen.
danke und Gruß
Gmeurb
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: 322312
Url: https://administrator.de/contentid/322312
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
4 Kommentare
Neuester Kommentar
Hi,
guck mal bei den Einstellung , siehe gelber Hinweis, was dort mit dem Vollständigem Überschreibschutz genau gemeint ist.
Das könnte daran liegen.
Ich kann es gerade mit meinem BE15 nicht nachsehen, da sich nach den letzten Updates die Konsole nicht mehr aufrufen lässt
VG,
Deepsys
guck mal bei den Einstellung , siehe gelber Hinweis, was dort mit dem Vollständigem Überschreibschutz genau gemeint ist.
Das könnte daran liegen.
Ich kann es gerade mit meinem BE15 nicht nachsehen, da sich nach den letzten Updates die Konsole nicht mehr aufrufen lässt
VG,
Deepsys
Hallo,
wie Deepsys schon geschrieben hat, sind die Einstellungen nicht gesetzt wie gewünscht.
Schau ins Manual, welche Einstellungsmöglichkeiten es gibt und wie sie sinnvoll eingestellt werden sollten.
Gruss Penny
wie Deepsys schon geschrieben hat, sind die Einstellungen nicht gesetzt wie gewünscht.
Schau ins Manual, welche Einstellungsmöglichkeiten es gibt und wie sie sinnvoll eingestellt werden sollten.
Gruss Penny
Hm, ich habe mir die Einstellungen angeschaut. Im Prinzip kommt die Einstellung "Überschreiboptionen" dem am nächsten was ich da gerade feststelle. Im Moment steht das nämlich wie im Anhang!
Da ich für Backups selbst einen Schreibschutz von 5 Wochen eingestellt habe und diese Sätze einmal im Monat rauswerfe könnte das eventuell das Phänomen ändern.
Ich schaue mir das mal über einen längeren Zeitraum an! Danke für den Tipp, melde mich wieder.
Gruß
Gmeurb
Da ich für Backups selbst einen Schreibschutz von 5 Wochen eingestellt habe und diese Sätze einmal im Monat rauswerfe könnte das eventuell das Phänomen ändern.
Ich schaue mir das mal über einen längeren Zeitraum an! Danke für den Tipp, melde mich wieder.
Gruß
Gmeurb
So, die Einstellungen bewirken hier keine Änderungen im Verhalten. Backup Exec merkt sich offensichtlich nicht, dass wenn ein Band während einem Backup voll läuft, dass es noch freien Space im eigenen Medienpool hat.
Das Verhalten ist vor allem bei differenziellen Backups sehr Band raubend. Eine Antwort über ein Forenbeitrag bei Symantec klingt ähnlich (siehe unten)!
Mein Workaround sieht so aus, dass ich die Bänder täglich beobachte und Bänder die schon ziemlich voll sind einfach in meinen entsprechenden Archivpool verschiebe. Temporäre Bänder halte ich in einem anderen Pool als eben ihrem eigenen. Dann nehmen sich die DIFF-Backups Bänder mit freiem Platz aus Ihrem Pool.
Wahrscheinlich werde ich auf inkrementelle Backups umschalten, da läuft das wesentlich bänderschonender ab.
Hmm ok I have a feeling I knwo what us happening
Backup jobs have no memory of whuch tape was used the day before by the same job
As such every time a job starts it looks at what is available - with an append job looking for available appendable tapes. However if there is more than one appendable piece of media available, in the same media set, when the job starts, then it does not base the choice of which tape to use on what the same job ran yesterday or how much space is free on a gven tape. It bases the choice on which of the appendable media was last written to the longest time ago. Which will means that a repetitive job may not choose the same tape to add to the next day.
if you use different media sets for jobs you want to keep on same chain of tapes (even if each media set has the same OPP and AP timings, it wil sort this out.) Nopte: You may have to consider different media sets for any jobs that run in parallel with each other as well if you havemultipel drives in the library.
Das Verhalten ist vor allem bei differenziellen Backups sehr Band raubend. Eine Antwort über ein Forenbeitrag bei Symantec klingt ähnlich (siehe unten)!
Mein Workaround sieht so aus, dass ich die Bänder täglich beobachte und Bänder die schon ziemlich voll sind einfach in meinen entsprechenden Archivpool verschiebe. Temporäre Bänder halte ich in einem anderen Pool als eben ihrem eigenen. Dann nehmen sich die DIFF-Backups Bänder mit freiem Platz aus Ihrem Pool.
Wahrscheinlich werde ich auf inkrementelle Backups umschalten, da läuft das wesentlich bänderschonender ab.
Hmm ok I have a feeling I knwo what us happening
Backup jobs have no memory of whuch tape was used the day before by the same job
As such every time a job starts it looks at what is available - with an append job looking for available appendable tapes. However if there is more than one appendable piece of media available, in the same media set, when the job starts, then it does not base the choice of which tape to use on what the same job ran yesterday or how much space is free on a gven tape. It bases the choice on which of the appendable media was last written to the longest time ago. Which will means that a repetitive job may not choose the same tape to add to the next day.
if you use different media sets for jobs you want to keep on same chain of tapes (even if each media set has the same OPP and AP timings, it wil sort this out.) Nopte: You may have to consider different media sets for any jobs that run in parallel with each other as well if you havemultipel drives in the library.
