Der Wunsch die Daten seiner Server auf Medien zu sichern und somit Datensicherheit zu erhalten hört nicht nur bei der Datensicherung auf Band auf, oft besteht auch der Wunsch oder Anforderung die beschriebenen Bänder vor weiterem Beschreiben zu schützen oder die Medien aus der Bandlibrary zu entfernen und an einem sicheren Ort (Tresor, Ausfall Rechenzentrum, …) zu verwahren. Jeder Data Protector Admin kennt diese Situation; Herausfinden welche Bänder in der letzten Vollsicherung beschrieben wurden um sie dann auslagern zu können. Der erfahrene Admin lässt sich dafür einen Report senden oder verwendet viele unterschiedliche Pools um die Tagessicherung, Wochensicherung und Monatssicherung auseinanderzuhalten. Problem: die Bänder sollen dann trotzdem noch in einen eigenen „Auslagerungspool“ verschoben werden, bevor sie der Library entnommen werden.
Lösung: Genau für dieses Problem habe ich ein kleines Perl Skript geschrieben. Wie immer schreibe ich meine Skripte in Perl, da diese Sprache sehr flexibel für solche einfachen Aufgaben ist. Das Skript benötigt keine vollständige Perl Installation, die abgespeckte Perl Variante die bei der Installation von Data Protector auf dem Cell Server enhalten ist reicht komplett aus. Funktionweise kurz: Es werden die Sicherungen eines Zeitraums bestimmt, die Medien dazu analysiert und diese dann in einen anderen Pool verschoben.
Funktionsweise: Das Skript durchsucht die Sicherungen des Timeframes der im Skript angegeben wird, für die Aufstellung der Sicherungen werden die verwendeten Bänder ermittelt. Die Liste der Bänder wird nun von eventuell vorhandenen Dubletten bereinigt (ein Band kann von mehreren Backupjobs verwendet wurden sein) und für jedes verbliebene Band der Pool bestimmt. Wenn das Band in einem Pool liegt welches über ein einzustellendes Exclude nicht verschoben werden soll, dann wird das jeweilige Band übersprungen, anderenfalls wird das Band in den konfigurierten Zielpool verschoben. Sollte die Anforderung an das Skript etwas komplexer werden so ist es auch mögliche mehrere Kopien des Skripts mit unterschiedlichen Werten für die Variablen einzustellen und laufen zu lassen. Das gilt auch für Medien unterschiedlichen Typs (LTO und was es sonst noch gibt…) Am Ende des Skripts wird dann noch eine Mail versendet mit der Information welche Bänder in den Zielpool verschoben wurden. Wer das nicht mag kann es gern auskommentieren… Wer es mag muss sich noch das Tool „Blat“ besorgen und konfigurieren – Link: http://www.blat.net. Der Einfachheit halber habe ich alles (das Skript, das Batchfile dazu und die Blat Binaries) in das Bin Verzeichnis von Data Protector gelegt, aber auch das kann geändert werden. Denkbar wäre auch noch eine Erweiterung wo die Bänder gleich noch in die Mailslots verschoben werden (5 Zeilen Code mehr). Das macht natürlich nur Sinn wenn die Library über konfigurierte Mailslots verfügt und die Anzahl der auszulagernden kleiner oder gleich der Menge der Mailslots ist.
Fallbeispiel: Es sind die Pools FilesystemWeekend, FilesystemDaily (für die Filesystem Sicherungen), DatabasesWeekend, DatabasesDaily (für Datenbank Sicherungen), DPDatabase, Vaulting und FreePool vorhanden. Am Montagmorgen sollen die Bänder die in den Sicherungen seit Freitag Abend verwendet wurden in den Pool „Vaulting“ verschoben werden. Die „Daily“ Pools und der DPDatabase Pool (Die Sicherung der internen Datenbank geht bei mir immer in einen eigenen Pool!) sollen in diesem Fall bei der Auslagerung unberücksichtigt bleiben. Welche Einstellungen im Skript vorgenommen werden müssen wird im nächsten Abschnitt gezeigt.
Einstellungen: Was muss im Skript auf Grund des Fallbeispiels geändert werden? Bitte unbedingt darauf achten, dass die @ Zeichen in den Mailadressen mit einem Backslash quoted sind und das vorher „blat“ konfiguriert wurde (ist nur ein Befehl absetzen).
$exclude_pools="FilesystemDaily,DatabasesDaily,DPDatabase,Vaulting";
$vault_pool="Vaulting";
$timeframe_start="60";
$timeframe_duration="60";
$mailrecipient="servicedesk\@data-protector.org";
$mailserver="127.0.0.1";
$mailsender="dataprotector\@data-protector.org";
$mailsubject="Media vaulting";
[wpdm_file id=4]
UPDATE Download: Es hatte sich ein kleiner Fehler bei der Bestimmung der Medien eingeschlichen, die Anzahl hatte nicht gestimmt – neuer Download nachfolgend.
[wpdm_file id=5]
Einsatzgebiet: Das Skript ist besonders für kleine bis mittelständige Umgebungen geeignet. In größeren Umgebungen empfehle ich das Konzept von HP Media Operations mal genauer anzuschauen. Alternativ können Sie auch ein Skript für größere Umgebungen bei mir erwerben, individuelle Wünsche können dabei berücksichtigt werden. Entsprechende Anfragen (mit dem Betreff: Off-Site Tape Vaulting) richten Sie bitte direkt an daniel-braun@data-protector.org
Donate: Und noch ein Wort am Ende… Wenn der Artikel und das Skript bei der täglichen Data Protector Administration weiterhilft und zum Einsatz kommt, so würde ich mich über eine Spende (nicht mehr wie 5 €) mittels PayPal freuen. Den Link findet ihr rechts oben…
Referenz: Und wen der Proxy ärgert… nachfolgend das komplette Skript. Wer es schlanker mag (das Skript kommt auch ohne die prints und mit der Hälfte der Zeilen aus), kann es gern anpassen…
#!perl -I../lib/perl -X -CA
### needed modules
use Omniback;
# Get DP folders
my $OMNIHOME = Omniback::CmnQuotePath($Omniback::PAN{'BASE'});
my $OMNIHOME_STR = $OMNIHOME;
$OMNIHOME_STR =~ s/\"//g;
my $OMNIBIN = "\"${OMNIHOME_STR}/bin\"";
# define the exclude pools, pool for vaulting, ...
$exclude_pools="Pool1,Pool2,PoolX";
# the pool mus exist in DP
$vault_pool="Vaulting";
# the time frame to retriev the session information
# assuming the script should run monday 8am, the timeframe of
# 60 month covers backups starting friday evening
$timeframe_start="60";
$timeframe_duration="60";
# the stuff needed to send a mail at the end of the script
# you need to download blat (mail program) search for blat at google
$mailrecipient="firstname.lastname\@domain.com"; # please remind the quoted (at)
$mailserver="192.168.2.10"; # the ip address of the smtp server
$mailsender="dataprotector\@domain.com"; # please remind the quoted (at)
$mailsubject="Media vaulting"; # Subject for the mail
print "Generating Report\n";
print "- skipping pools: $exclude_pools\n";
print "- target pool is: $vault_pool\n";
print "- start time: $timeframe_start\n";
print "- duration: $timeframe_duration\n";
print "\n\nNote: Ignore messages regarding \"No medium found\"\n\n";
@exec=`${OMNIBIN}/omnirpt -report list_sessions -timeframe $timeframe_start $timeframe_duration -tab`;
foreach (@exec)
{
chomp $_;
next if /^#/;
(@sessionid)=split(/\t/,$_,23);
push(@sessions,$sessionid[22]);
}
foreach (@sessions)
{
@exec=`${OMNIBIN}/omnidb.exe -session \"$_\" -media`;
$media = $exec[2];
chomp $media;
($media_short,$dummy)=split(/ /,$media,2);
if ($media_short ne "")
{
push(@media,$media_short);
}
}
@newmedia=&del_double(@media);
print "Summary\n";
@movedmedia=();
foreach (sort(@newmedia))
{
($media1,$dummy)=split(/ /,$_,2);
$media1 =~ s/\[//ig;
$media1 =~ s/\]//ig;
@exec=`${OMNIBIN}/omnimm -media_info \"$media1\" -detail`;
$pool = $exec[2];
chomp $pool;
chop $pool;
$pool =~ s/Pool name : //ig;
if ($exclude_pools =~ /$pool/)
{
print "skipping media: $media1 \n";
}
else
{
print "moving media: $media1 \n";
@exec=`${OMNIBIN}/omnimm -move_medium \"$media1\" $vault_pool`;
push(@moved_media,$media1);
}
}
$anzahl=@moved_media;
if ($anzahl gt 0)
{
$message="";
$message="Vaulting media:\n============================\n\n";
$message=$message."Following media were moved to pool: $vault_pool for vaulting.\n";
$message=$message."Media:\n";
foreach (@moved_media)
{
$message=$message.$_."\n";
}
$message=$message."\n\nMail generated by robot\n\n";
`${OMNIBIN}/blat -to $mailrecipient -f $mailsender -subject \"$mailsubject\" -body \"$message\"`;
}
exit;
sub del_double{
my %all;
grep {$all{$_}=0} @_;
return (keys %all);
}
Nice little trick – but why would you need to move it to a vaulting pool? Moving does not change any properties on the physical media, label nor the data/catalog retention enforcement so how does this make it easier for the backup admin compared to a used media report in his mailbox that kicks off at the end of the job?
I also disagree with the need for that many media pools, admins generally prefer to have homogenous retention times for as much data in their environment as possible (where it makes sense ofcourse). Firstly then homogenous retention times makes defining or revising a backup SLA a much less complicated task. Secondly there would be less media pools for the backup admin to supervise so administration is easier, and thirdly you have less unused space left on media in your vault locations. In your example above then at the typical customer, the full backup sets for both file, db and idb data would be vaulted for the same time but would be residing on minimum 3 media – none of which would be full – thats a lot of wasted capacity and money out the window if eg. using a simple gfs-rotation scheme for a year.
/Morten
Hi Morten, Yes you are right this will not change anything on the media. At least I set the vaulting pool to non appendable. Regarding your question, I personally do not care about the pools too; however, this is what I learned from customers to have such a vaulting pool and to have media with full backups moved to a special pool. In addition many customers don’t like to mix incremental and full backups on the same media. Thats why I created the script. In this case the customer don’t need to search different pools manually, he just have to have a look in one pool. When taking media off-site the customer could go to slots, sort for the pools, mark te media and select eject. Of course for an expert like you and me this is not a big deal and we would not need such a script, but not all DP admins are experts 🙂
This worked great. Do you have a sample of a script to bring the Vaulted tapes back into the silo and DP? We are having trouble with that.
Hi, no, but its quite easy, please contact me directly.
I cant seem to find your email address. How do I contact you directly?
Austin, it’s just daniel-braun(at)data-protector.org or daniel-braun(at)db-productions.de