Hallo,
gegeben ist ein Rechner mit RDX Wechselplatten und einem LTO Bandlaufwerk. Auf Grund der Medienkapazitäten und -verfügbarkeiten sieht das Konzept zwei RDX für im Wechsel je eine Komplettsicherung Sonntags und 6 LTO für die inkrementelle Sicherung an den restlichen Tagen vor.
Mein Problem ist jetzt das automatische Recycling der LTO Bänder. Hier mal die Definition der Pools:
Pool { Name = RDX_Pool Pool Type = Backup Recycle = yes AutoPrune = yes Volume Retention = 12 days Maximum Volume Bytes = 640G Maximum Volumes = 2 Use Volume Once = yes Maximum Volume Jobs = 2 Volume Use Duration = 12 days Storage = "RDX_Storage" }
Pool { Name = LTO_Pool Pool Type = Backup Recycle = yes AutoPrune = yes Volume Retention = 6 days Maximum Volume Bytes = 400G Maximum Volumes = 5 Use Volume Once = yes Maximum Volume Jobs = 1 Volume Use Duration = 5 days Storage = "LTO_Storage" }
Pool { Name = Scratch Pool Type = Backup }
Ich interpretiere meine Einstellungen (LTO_Pool) ja so: - sperre ein Band nach erfolgreichem Job 5 Tage fürs ANHÄNGEN (use duration), sprich markiere es als USED statt APPEND - schütze (retention) das Band nach erfolgreichem Job für 6 Tage
Was funktioniert, ist, dass ein Tape mit Nutzung auf den Status USED fällt. Ferner klappt das pruning, da ca. einen Tag vor geplanter Wiederverwendung zum Medium der Job verschwindet (in der Medianansicht). Die Doku sagt nun, dass wenn kein APPENDable Medium da ist, keines im Scratch ist und keines recycled/unused - nach Medien gesucht wird, die gepruned sind, sprich keine Jobs mehr enthalten. Das ist bei mir doch der Fall: ich habe 6 Bänder USED und das eingelegte hat keine Job mehr laut Katalog verknüpft. Warum wird das nicht recycled sondern der Job fragt den admin, ob der nicht mal ein Tape lablen könnte? Recycle ich das eingelegte Tape sichert der Job los.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Ich habe einen Ansatz.
In der Doku gibt es einen Satz, der besagt, dass das Medienmanagement (autoprune/autorecyles) am Ende eines Jobs stattfindet und in den Zeiten, in denen KEIN volume vorliegt.
Bei einer geplanten Sicherungszeit von 23 Uhr, Medienwechsel gegen 10 Uhr und administrativem Eingriff (recycle + Sicherung) gegen 16 Uhr würde das bei einer "retention" von Sicherungszyklus-1d bedeuten, dass kein Volume zum recyclen da war, als der letzte Job fertig wurde. Ich habe die "retention" um einen weiteren Tag verkürzt, mal sehen. Leider öffnet das der Volumeverwechselung nun Tor und Tür.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Hab das mal unserem für Backups zuständigen Admin vor die Füße geworfen, Rest=ungeprüftes Zitat.
" 1. use duration sollte eine zeiteinheit (tag,stunde,etc.) weniger betrage, als zwischen zwei sicherungen des gleichen levels (täglich,wöchentlich,monatlich,...) vergehen. "archivsicherungen" weichen dort nach weit unten ab. 2. use volume once (wenn es das tut, was ich denke, das es tut, heißt es, dass das volume als worm betrachtet wird -> nicht recycled) 3. Maximum volume jobs sollte man nur bei vtl's verwenden, denn sonst verschwendet man bandplatz, und nutzt diese auch mehr ab, weil man jeden job auf ein einzelnes band schreibt 4. außerdem hat er beim lto-pool maximum volumes =5 angegeben, sollte aber bei dem setup 6 sein 5. vol retention fängt am ende des letzten jobs auf einem band zu laufen. also startzeit+backup-laufzeit. 6. der ablauf beim suchen eines volumes ist: 1.appendable volume im pool 2.pruned volume im pool -> recycle 3.appendable volume im scratch pool (konfigurierte eigenschaft des pool, nicht der _name_ scratch) 4.pruned volume im scratch pool 5.prunen aller prunnablen vols -> jump 3. (hintergrund ist der, dass man im pool einen "recycle pool" angeben kann, in den die vols verschoben werden, wenn man ein vol pruned) 7. bei einem lto sollte man keine maximum volume size angeben, da diese nicht fest ist, sondern von der effizient der hardware compression abhängig ist. (z.b. bei lto3 zwischen 400G und 600G)
meine erste vermutung wäre punkt 2 "
Hi Carsten,
- use volume once (wenn es das tut, was ich denke, das es tut, heißt
es, dass das volume als worm betrachtet wird -> nicht recycled)
Dieses Option : es schreibt nur einen Job aufs Band (volume), ist da noch Platz wird aber kein zweiter dort abgelegt, recycled wird aber trotzdem.
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
Am Mon, 31 Aug 2015 15:03:22 +0200 schrieb "Ronny Seffner" ronny@seffner.de:
Dieses Option : es schreibt nur einen Job aufs Band (volume), ist da noch Platz wird aber kein zweiter dort abgelegt, recycled wird aber trotzdem.
D.h. es ist inhaltlich identisch zu Maximum Volume Jobs = 1 ?
Hallo Carsten,
Dieses Option : es schreibt nur einen Job aufs Band (volume), ist da noch Platz wird aber kein zweiter dort abgelegt, recycled wird aber trotzdem.
D.h. es ist inhaltlich identisch zu Maximum Volume Jobs = 1 ?
Aus dem manual:
Pool Options to Limit the Volume Usage To write nnn Jobs to each Volume, use: Maximum Volume Jobs = nnn
und an anderer Stelle:
"Use volume once" directive is marked as deprecated. Recommended directive for this case is "Maximum Volume Jobs = 1".
Mit freundlichen Grüßen / Kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ronny@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB8
lug-dd@mailman.schlittermann.de
-
Carsten Weber -
Ronny Seffner