Dieser Post in ein Sammelthread, in welchem ich Ihnen erkläre, wie Sie in verschiedenen Datenbankmanagementsystemen Backup-Dumps einer Datenbank erzeugen und sie an anderer Stelle wieder einspielen. Derzeit fehlen noch einige Datenbanksysteme wie beispieslweise DB2 und MS SQL. Es fehlen noch alterantive anstäze die XML-Datenbanken oder noSQL. Der Post wird regelmäßig geupdatet und dadurch aktualisiert.

SQLite

Eienn  Dump einer SQLite-Datenbank erzeugt irh mit dem kommandozeilentool sqlite3. Ihr meldet euch an sqlite an über

sqlite3 <dateiname der datenbank>

Da in SQLite alles über Dateien geregelt wird, müsst ihr den Dateinamen der Datenbank angeben.

Um nun von einer Datenbank ein Backup-Dump zu mahen, gebt ihr ein

.dump

Wenn ihr euch ein Skript schreiben wollt, um einen SQLite-Dump machen zu könne, könnt irh das unter Linux beispielsweise so realsiieren

echo '.dump' | sqlite3 <dateiname datenbank> | gzip -c >ex1.dump.gz

soe rahtlet ihr autamtisch ein komprimiertes Backup der Datenbank.

Das Wiederherstellen des daraus erzeugten Backups geht einfach über

zcat ex1.dump.gz | sqlite3 <name neue datenbank>

PostgreSQL

database Dump

die klassische Backupfrom ist der Dump in ein textbasiertes .sql-File. das geht über den Befehl pg_dump

pgdump <datenbankname> > <dateiname backupdatei>

Das Backup kann dann foglendermaßen wieder eingelesen werden

pgsql dbname < infile

Mit diesem Befehl ist es aber nur möglich, einzene Datenbanken zu dumpen. Wenn Sie ein ganzes System mit allen Datenbanken inklusive rollen und Tablespaces dumpen wollen, dann nutzen Sie den Befehl pg_dumpall

pg_dumpall > <dateiname backupdatei>

Diesen Dump können Sei dann wiederherstellen mittels

pgsql -f <dateiname> postgres

MongoDB

Unter mongoDB können Sie die Datenbank mit dem Tool mongodump wegsichern. Ein Dump des gesamten sErvers amchen Sie mit

mongodump --host <FQDN oderlocalhost>

Ein Backup einer einzelnen Datenabnk machen Sei mit

mongodump -db <datenbankname> --collection <collection name = sammlung der backupdateien>

Das wiederhestellen geht dann über

mongorestore --db <datenbankname> <pfad zur .bson datei>

 

MariaDB und MySQL

MariaDB und mySQL dumpen Sie mti dem Befehl mysqldump

mysqldump <datenbankname> > <dateiname backupdatei>

Wiederherstellen können Sie ein solcehs Backup mittels

mysql <datenbankname> < <dateiname backupdatei>

Dateisystembackup

unter amriaDB und mySQL können sie neben der klassischen methode des Databasedumps auch ein Backup auf Dateisystemebene machen. Das geht jedoch nur unter der Engine MyISAM. Wenn Sie hingegen für ihre Datenbank die Engine XtraDB oder InnoDB verwenden, geht es nicht.

sie können bei einer myISAM-Engine also eentweder die Dateien mit den Endungen .frm, .MYI und .MYD, .ISD und .ISM kopieren. Deise Form des Backups ist jedoch nicht empfehlenswert, da Sie das Backup oftmals nur auf Systemen mit gleicher Architektur und eventuell sogar nur utner gleichem Betriebssystem zurückspielen können.

Dieses Dateisstembackup können Sie auch über das kommadnozeilentool mysqlphotcopy machen.

mysqlhotcopy <datenbankname> <verzeichnis, in welches die Dateien kopiert werden sollen>

XtraBackup

In mariaDB ist außerdem stndardmäßig das Tool XtraBackup integriert.  Beim Afuruf von xtrabackup müsst ihr darauf achten, dass ihr die richtige Binary ausführt. Xrabackup_55 ist für mySQL Version 5.5 geeignet, Xtrabackup_51 für mysql 5.1.

ein Backup nehmen sie dann über

innobackupex /<backupverzeichnis>

innobackupex --aply-log /<backupvezreichnis>

Das wiedehrestellen geht dann über

copy /<backupverzeihcnis> <datenbankverzeichnis>

 

Oracle

Um ein Oracle-Backup sauber planen zu können, muss man kapieren, wie Oracle seine Daten sichert.

Multiplexing

Warum man Files die control Files oder die Online REdo Log Files mutiplex, erfahren Sie in meinem Thread Oracle DBMS – theoretisches Grundwissen.

als erstes können Sie mit folgendem komamndo prüfen, ob Ihre online Redo Log Files gemultiplexed werden:

select * from v$logfile;

 

Archivierung der RedoLog Files

Was RedoLog Files sind und wieso man sie archivieren sollte, lernen Sie in meinem Thread Oracle DBMS – theoretisches Grundwissen.

Als erstes sehen wir uns die parameter unserr Recovery-Konfiguration an.

show parameter recovery

Als nächstes müssen wir mit folgendem Befehl sicherstellen

archive log list;

dass Automatic Archival aktiviert ist und ein pfad für das Archiv gesetzt ist. Falls nicht, können wir die Destination für Archive-Logs  setzen. Dabei sollten Sie antürlcih mehrere Destinationen setzen, damit die Redo Log Files wieder über mehrere Datenträger hiwneg gemirrort werden.

ALTER SYSTEM SET log_archive_dest_1 = "LOCATION=C:\pfad\zum\archiv MANDATORY REOPEN=300" SCOPE=BOTH

ALTER SYSTEM SET log_archive_dest_2 = "LOCATION=D:\pfad\zum\archiv MANDATORY REOPEN=300" SCOPE=BOTH

 

Oracle-Dump über SQLPlus

Über sqlplus können Sie einen Oracle-Dump über die Kommandozeile erzeugen. Loggen Sie sich als Administrator des systems ein

sqlplus / as sysdba

Oracle wird das Backup ohne zusätzliche Angabe in ein vorher festgelegtes Standardverzeichnis speichern. Mit diesem Befehl prüfen sie, ob ein derartiges Verzeichnis bereits gesetzt wurde.

SELECT * FROM DBA_DIRECTORIES;

falls dieses Verzeichnis noch nicht existiert, können Sie es erstellen

$>mkdir /oracle/dumps

SQL>create directory DUMPDIR as '/oracle/dumps';

SQL>grant all on directory DUMPDIR to <myuser>;

Den grant befehl müssen Sie nicht anwenden, wenn der dump durch einen DBA-Useraccount durhcgefürht wird.

Den Dump selbst legen Sie nun an über

$>expdp system/manager schemas=user1 dumpfile=user1.dpdmpf

Sie können den dump jedoch auch in ein vom Stndardverzeichnis abweichendes Verzeichnis exportieren

$>expdp system/manager schemas=user1 dumpfile=user1.dpdmp directory=/path/to/dir

Sie wählen zum Dumpen ein Schema aus. Eine Übersicht aller Schemas auf dem Oracle-System bekommen Sie über

SELECT username FROM dba_users;

wenn Sie eine Oracle-Version verwenden, die expdp noch nicht kennt, müssen Sei das tool exp verwenden

$>exp system/manager owner=user1 file=user1.dmp

Sie müssen noch sicher gehen, dass der Oracle Dump mit dem selben Zeichensatz gemacht wird, in dem die Datenbank derzeit vorliegt. wenn sie ihre Oracle-Umgebungsvariabeln nicht sauber gesetzt haben kann es sein, dass der Zeicehnsatz des Oralce-Cleints nicht der selbe ist wie der, der für die Datenbank verwendet wird. Dann bekommen Sie beim Dumpen eine warnung. Sollten Sei diese bekommen, brechen Sie den Dump ab und setzen die umgebungsvaraibleb NLS_LANG.

Sie checken den aktuellen Zeichnsatz der Datenbank über

SQL> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';

#oder

SQL>SELECT * FROM NLS_DATABASE_PARAMETERS

Bei den meisten Datenbanken sollen Sei heir den wert AL32UTF8 rausbekommen. Jedenfalls müssen Sie sichergehen, dass der hier raubsekommene wert als System-Umgebungsvariable gesetzt ist.

#Linux

$>expport NLS_LANG=AMERICAN_AMERICA.AL32UTF8

#Winodws

C:\>set NLS_LANG=AMERICAN_AMERICA.AL32UTF8

Backup auf Dateisystemebene

Sie können auch einfach die Datenbank herunterfahren

SQL>shutdown immediate

# wenn das ewig braucht

SQL>alter system checkpoint;

SQL> shutdown abort

SQL>startup restrict

SQL>shutdown immediate

und dann auf Dateisystemebene alle Data Files, Control Files und Log Files wegsichern. Eine Liste aller Dateien, die gebackupt werden müssen erhalten Sie mit folgenden Abfragen

SELECT NAME FROM sys.v_$datafile;

SELECT member from sys.v_$logfile;

SELECT name FROM sys.v_$controlfile;

Diese Dateien müssen Sie einfach wegsichern, danach können Sie die datenbank wieder starten.

Online-Backups

Sie können eine Datenbank auch backupen, wärhend sie weiterläuft und User darauf arbeiten. in diesem Fall wird der aktuelle Stand der Datenbank gebackupt, zu welchem sie das Backup strten und zusätzlich werden während des Betriebs der datenbank sogenannte Archive Logs geschrieben, welche die Änderungen zur Zeit während des Backups enthalten. Das Datenbank Backup in Verbindung mit den Archive Logs versetzt Sie dazu in die Lage, den Stand der Datenbankn zurückzuspielen der vorherrschte, nachdem das Backup beendet wurde.

als erstes müssen Sei die Datenbank dazu in den sogenannten Backup-Mode versetzen. Es empfiehtl sich dabei, nicht sofort die gesamte Dtaenbank in den Backup-mode zu versetzen,s ondern Tablespace für Tablespace zu sichern.

ALTER TABLESPACE <xyz> BEGIN BACKUP;

!cp|dd <File.dump> /backupverzeichnis/

ALTER TABLESPACE <xyz> END BACKUP;

Eine Liste aller Dateine, die Sie wzischen den beiden alter-tablespace-Kommandos wegsichern müssen, bekommen Sie über

select file_name from dba_data_file where tablespace_name = '<xyz>';

Nach den Backups der tablespcaes müssen Sei dann die erstellten Control Files wegsichern.

ALTER SYSTEM SWITCH LOGFILE

ALTER DATABASE BACKUP CONTROLFILE TO '/backupverzeichnis/control.dbf';

Danach müpssen Sie nioch das aktuelle online-Redo-log-File archivieren lassen

alter system archive log current;

und dann alle archivierten Archive Logs in ein Sicherungslaufwerk kopieren lassen.

Falls ihre Datenbank während des Backup Modes abstürzt, können Sei die Datenbank wieder hoch bringen, indem Sie die im backup mdoe befindlichen Datafiles aus dem backup modus rausnehmen. Ab Oralce 9.2 geht das einfach über

ALTER DATABASE END BACKUP;

Offline-Backup über RMAN

Der oracle Recovery Manager ist ein Oracle Utily zum Backupen und Weidehrerstellen von Oracle Datenbanken. RMAN kommt mit dem Datenbankserver und braucht keine extra installation. Die Binary befindet sich im Verzeichnis %ORACLE_HOME%\bin.

Der RMAN kann sowohl online als auch offline Datenbankbackups machen. RMAN kann jedoch von Hause aus nicht direkt auf Magnetbänder schreiben. Es gibt aber Drittanbeiterlösungen von Veritas, Omiback etc., die diese funktioanlität mitbringen würden.

RMAN ist eine Binary-Executable, die standardmäßig mit Oracle mit installiert wird. RMAN kann über RMAN-Batch-Skripte automatisiert werden. Skripte werden dazu in einer proprioetären RMAN-Skriptsprache geschrieben und haben standardmäßig die Dateiendung .rman.

Bei einem RMAN-Backup muss man zunächst untershcieden zwischen einer Image Copy und einem Backup Set. Eine image copy ist einfach nur ein simples Kopieren aller wichtigen Dateien (Control File, Redo Logs, Archive Logs und Datendateien) ohne Kompression. Ein Backup Set ist eine komprimierte Varainte dieser Kopie in einem oracle-proprietärem Dateiformat. Und nicht nur ist dieses Backup komprimiert: es kopiert auch nur genutzte Oracle-Block-Einheiten. Oracle-Blocks, die zwar von der Oracle-Datenbank im Dateisstem reserviert sind, aber leer sind, also ohne Daten, werden nicht kopiert. Deswegen ist das Backup Set auch die empfehlenswerte Methode.

Als erstes müssen Sie ein .rman-Skriptfile schreiben, in welchem Sie ihr Backup festlegen. Eine solche Skriptdatei sollte dabei die Befhle zum sauberen herunterfahren der Datenbank enthalten, so dass ein Checkpoint passiert und alle Änderungen in die Datendateien geschrieben werden (siehe Theoriepost), danach die Oracle-Instanz gestartet wird ohne die Datenbank dabei zu öffnen und dann das Backup selbst durchzuführen und zu guter letzt die Datenbank wieder zu öffnen, damit sie von den Benutzern nach dem Backup wieder verwendet werden kann. Ein solches skript könnte etwa so aussehen

run{

shutdown immediate;

startup mount;

allocate channel <channelname> type disk;

backup as bset1 database;

format 'E:\Pfad\zum\Backup.bus';

alter database open;

}

Nachdem Sie das .rman-Skript geschrieben haben, können Sie das Skript auf Kommandozeilenebene ausführen über

rman target sys/<passwort>@<DBSID> @<Pfad zur Skriptdatei>

Die einfachste Methode ohne Schreiben eines .rman-Skripts ist, die Datenbankaparameter DB_RECOVERY_FILE_DEST_SIZE und DB_RECOVERY_FILE_DEST zu setzen. Diese Parameterwerte liest RMAN und bekommt dadurch einen Standarddateipfad, in welchen er automatisch Backups speichern soll. Sie können dann ein RMAN-Backup ohne eine .rman-Skriptdatei starten, indem sie folgende Schritte durchführen

$>sqlplus

SQL>connect / as sysdba

shutdown immediate;

startup mount;

exit

$>rman target / backup database;

$>sqlplus

SQL>connect / as sysdba

SQL>alter databse open;

Hier wird also erst die Datenbank heruntergefahren und dann im mount-modus gestartet und anschileßend rman so gestartet, dass er mit Hifle der beiden oben genannten APramter ein automatisches Backup in den Dateipfad von DB_RECOVERY_FILE_DESt macht. Nach dem Backup wird dann die Datenbank wieder geöffnet, so dass wieder produktiv mit der datenbank gearbeitet werden kann.

Das kommando rman target / backup database backupt die gesamte Datenbank. Sie können auch nur einzelne tablespaces backupen mittels

rman target / backup tablespace users;

Über den RMAN können Sie auch automatisch irhe Controlfiles backuepn lassen.

RMAN>configure controlfile autobackup on;

Sie können für diese autobakcup auch den pfad angeben

RMAN>configure controlfile autobackup format

2>for device type disk to 'C:\pfad\zum\controlfile\backup\controlfile_%F';

Auch das SPFILE können Sie als PFILE speichern über

RMAN>backup spfile;

 

Online-Backup über RMAN

Das Skript für den RMAN sieht beim onlone-Backup so aus

run {

allocate channel c1 type orcl_tape;

allocate channel c2 type orcl_tape;

backup as compressed backupset filesperset 6 database;

backup as compressed archivelog all delete all input;

}

inkrementelle Backups mit RMAN

bei einem inkrementellen Backup amchen Sie beispielsweise einmal pro Woche ein volles Datenbankbackup und die restlichen 6 Tage nur ein inkrementelles Backup, welches nur jeweisl die Änderungen im Vergleich zum Vortag enthält. Das spart Speicherplatz und Performance / Downtime.

Das erste volle Datenbankbackup geht über

backup as backupset incremental level 0 database;

Danach alle weiteren inkrementelle Backups über

backup as backupset incremental level 1 database;

kumulatives Backup über RMAN

bei einem inkrementellen Backup speichern Sie beispeislweise einmal pro Woche ein level 0 Backup, welches ein vollstädniges Backup darstellt, und speichern alle 6 Tage danach nur noch inkrementelle Backups, die die Änderungen im Vergleich zum Vortag enthalten. Um die Datenbank am Tag 7 wiederherzustellen, müssen Sie erst das Level 0 Backup wiederherstellen und danach die restlichen 6 inkrementellen Backups hintereinander durchgehen.

Bei eienm kumulativen Backup speichern Sie einmal ein Level 0 Backup und dann jeden Tag ein kumulatives Backup, welches alle Änderungen im Vergleich zum letzten Level-0-Backup enthält. Das bedeutet, Sie brauchen jeden Tag für das Backup etwas länger als beim inkrementellen Backup, da Sie mehr und mehr Änderungen pro Tag wegsichern müssen, je weiter Sie sich vom letzten Level 0 Backup entfernen. Jedoch brauchen sie weniger Zeit für Ihr Recovery, da sie nur noch das Level 0 Backup und das letzte kumulative Backup zurückspielen müssen.

backup as backupset cumulative database;

Backup über Enterprise Manager

über den Oracle Enterprise manager können Sie viele der oben geannnten Backups über eine grafische Oberfläche machen.

Dazu begeben Sie sich erstmal im Oracle EM angekommen nach Availability / Manage / Manage Current Backups. Dort finden Sie bisher bereits stattgefundene Backups, falls vorhanden.

Ein neues bakcup könenn Sei amcjhen über Availability / Manage / Schedule Backup.

Recovery von Backups über Oracle

Data Recovery advisor

Der Recovery Advisor ist ein gutes Tool, welches über den Oracle Enterprise Manager erreicht werden kann, welches Tipps für Recoverystrategien gibt.

Controlfile restoren

Wenn ihr ein Autobackup kofniguriert habt, könnt ihr ein Controlfile über RMAN eventuell restoren über

RMAN>restore controlfile from autobackup;

ansonsten könnt ihr euch den Speicherort der controlfiles anzeigen lassen und ein funktionierendes Backup des Control Files da hin kopieren, wo das Control File korrupt ist.

Redo Log File wiederherstellen

Wenn Sie wie weiter oben beschrieben ihre Online Redo Log Files gemultiplexed haben, können Sie ein Redo Log Member, welches ausgefallen ist, wiederherstellen über

alter database clear logfile group <nummer>;

Es anmcht dann außerdem sinn, einen Log Switch sowie einen Check Point zu erzwingen und alle besthenden Logs gleich zu archivieren

alter system switch logfile;

alter system checkpoint;

alter system archive log all;

Datendateien wiederherstellen

• datenbank im mount-modus öffnen
• die beschäditen datendateien offline nehmen
• die beschädigten files wiederherstellen
• die datenbank öffnen
• die wiedehrergstellten files iweder online bringen

 

 

 

Oracle Recovery Catalog aufsetzen

Für den REcovery Catalogue sollten Sie eine extra Datenbank mit extra Listener-Prozess erstellen.

wir brauchen einen Tablespace, der unseren REcovery Catalogue enthält

create tablespace catab;

Jetzt erstellen wir einen User der Objekte in diesem Tablespace beseitzten wird

create user rman identified by <passwort>;

Jetzt fügen wir Attribute zu diesem User hinzu

alter user rman temporary tablespace temp default tablespace catab quota unlimited catab;

Jetzt geben wir noch Rechte

grant recovery_catalog_owner to rman;

jetzt gehen wir aus SQL raus und gehen in RMAN

rman target <DBSIDCatalog>

RMAN> connect catalog rman@<DBSIDCatalog>

Jetzut erstellen wri den Katalog

RMAN> create catalog;

Jetzt msüsen wir in diesem Katalog die Datenbanken registrieren.

RMAN>register database;

Jetzt können wir mit RMAN arbeiten

rman target / catalog rman@<DBSIDCatalog>

 

 

 

Backup über Tivoli

Backup üver Veritas

SAP ASE und Sybase ASE

Unter Sybase ASE erstellen Sie erst eine Dump-Konfiguration für die Datenbank. Einloggen in das System über

isql -Usa -S<DB SystemID> -w2000

Danach

SQL>use master

SQL>go

SQL>sp_config_dump @config_name='<DB System Instanz>DB',

@stripe_dir='/<speicherort>',

@compression='101',

@verify='header'

SQL>go

Dann erstellen sie noch eien Config für die Transaction Logs

SQL>use master

SQL>go

SQL>sp_config_dump @config_name='<DBSID>LOG',

@strip_eidr='<speicherort (anderer als für die db)>',

@compression='101',

@veirfy='header'

Starten Sie die sybase Datenbank neu und loggen Sie sich wieder ein. jetzt erstellen sie foglendermaßen einen Dump. Als erstes schalten wir die datnebank in den Single user mode

SQL>sp_dboption

SQL>go

Wir warten 30 Sekunden und flushen die aktualsieirten Pages

SQL>checkpoint

SQL>go

Jetzt dumpen wir erst die datenbank selber

SQL>dump database <datenbankname> using config=<DBSID>DB

SQL>go

Danach dumpen wir die transaction Logs zu der Datenbank über

SQL>dump transaction <datenbankname> using config='<DBSID>LOG'

SQL>go

 

 Backups über Datenbankfrontends

– to be continued-

backups über virtualisierungslösungen

Die eifnachste form eines Backups wird ihnen natürlich gegeben, wenn Sei den Server, auf welchem die Datenbank läuft, virtualsiiert haben. Wenn der Datenbankserver beispielsweise als virtuelle Maschine auf einem VMWare vSphere Host läuft, können Sei einfach die Datenbank herunterfahren und dann einen Snapshot von der gesamten virtuellen maschine anfertigen.

Backups über Dateisystemsnapshots

einige Dateisysteme wie etwa Veritas unterstützen das Anfertigen von Snapshots. das können Sie sich ungefähr so vorstellen wie die snapshots einer virtualisierungssoftware, beispielsweise bei VMWare. Siekönnen afud iese Snapshots wieder zurückgehen und somit einen alten Dateisystemstand weiderherstellen. Dabei können Sie ntweder das gesamte Dateisstem oder nur einzelne Ordner auf dem Dateisystem snapshoten.

Das folgende Beispiel erstellt unte rdem Dateisystem VxFS einen Snapshot des Verzeichnis /srv/mongodb, in welchem sich eine MongoDB-Instanz befindet. Dieser Snapshot wird unter /dev/vx/dsk/fsvol/mongosnap und mountet diesen nach /mongosnapmount

mount -F vxfs -o snapof=/srv/monodb, snapsize=32768 /dev/vx/dsk/fsvol/mongosnap /mongosnapmount

Das Dateisystem, welches unter /mongosnapmount gemountet ist, kann nun bei Bedarf jederzeit wieder nach /srv/mongodb zurückkopiert werden. Das Dateisystem lässt sich auch einfach von /mongosnapmount auf einen belibigen Backup-Datenträger kopieren, um ihn zu archivieren. Dazu nutzt man am besten das Tool vxdump. Im foglenden Beispeil kopieren wir /mongosnapmount auf ein Magnetlaufwerk /dev/rmt

vxdump -cf /dev/rmt /mongosnapmount

Dieses Backup könenn Sie jetzt jederzeit mit dem tool vxrestore wiederherstellen. Im foglenden Beispeil löschen wir den aktuellen Stand von /srv/mongodbstellen wir das Dateisystem as dem Magnetband /dev/st1 wieder her

cd /srv/mongodb

rm *

vxrestore -v -x -f /dev/st1

 

Backups über LVM

Wenn Sie auf dem Betriebssystem, auf welchem die Datenbank läuft, LVM eingerichtet haben (Logical Volume Manager, verfügbar auf Linux/Unix Betriebssystemen), dann können Sie von einem logischen Volume einen snapshot enhmen und diesen bei Bedarf später zurückspielen. Vor einem solchen LVM Snapshot sollten Sie die Datenbank entweder ganz ehrunterfahren oder die Datenbanken sperren. Unter mongoDB geht das beispeislweise über db.fsyncLock();. Nach dem Update müssen Sei die Datenbank wieder hochfahren bzw. entsperren.

Als Beispeil erstellen wir mal einen Snapshot eienr MongoDB-Instanz, die auf dem Betriebssystem unter /srv/mongodb ist und als logical volume unter /dev/vg0/mongodb abgelegt ist. vg0 ist die Volume Group und mongodb ist das logische Volume, in welchem die mongoDB-Datenbank sitzt. /dev/vg0/mongodb wird von LVM in das Verzeichnis /srv/mongodb gemountet. Wir erstellen ein Backup mittels

lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb

Der Snapshot wird als logisches Volume gespeichert. in unserem Beispeil können wri den Snapshot als neues Logical Volume unter /dev/vg0/mdb-snap01 erreichen und an einer beliebigen Stelle im Dateisystem mounten. Der paramter –size 100M gibt die maximale Görße des Snapshots an. Wenn diese Größe zu klein bemessen ist, kann der snapshot nicht verwendet werden. Beim ersten Sanpshot sollten Sie als Größe etwas mehr asl die aktuelle Größe des volumes nehmen, da der erste Snapshot sozusgaen ein 1:1 Image ist. Danach müssen Sei wissen, dass ein Snapshot immer nur die Änderungen von einem zum nächsten Snapshot speichert. Wenn also im Vergleich zum letzten Snapsjhpt 100 MB an Daten hinzugekommen sind,d ann wird der nächste Snapshot etwas größer als 100 MB werden, ob wohl die Datenbank an sich 2 GB groß sein kann. Es kann aber sein, dass sie für den Snapshot, obwohl das Verzeichnis nur um 100 MB größer geworden ist, trotzdem 150 MB brauchen, weil vielleicht 50 MB an Datensätze gelöscht und durch neue 50 MB an neuen Datensätzen ausgetauscht wurden. Hier ist also Ihr Einschätzungsvermögen gefragt. im Zweifel setzen Sie das cap für den Snapshot lieber zu groß als zu klein. Nachträglich können Sie den Snapshot ohnehinn nochmal komprimieren mittels

umoutn /dev/vg0/mdb-snap01

dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz

Jetzt können Sie theoretisch  das logical Volume löschen mit lvremove. Wenn Sei den Snapshot irgendwann zurückspeilen wollen, können Sie dann mit lvcreate wieder ein logisches Volume anlegen, in welchem die gesamte mongoDB hinenpasst und die .gz-Datei in dieses logische Volume wieder entpacken. Im Anschluss daran können Sie das logische Volume beispielsweise nach /srv/mongodb mounten und schon ist ihre alte MongoDB wieder online.

Das ganze sähe dann so aus

umount /dev/vg0/mongodb

lvcreate --size 1G --name mdb-new vg0

gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new

mount /dev/vg0-mdb-new /srv/mongodb

BeIn diesem Fall unmounten wir das logishce volume mit dem derzeitigen STand der mongodb (die mongoDb-instanz sollte vorher heruntergefahren werden!), erstellen dann ein neues logische Volume und spielen dort den komprimierten Snapshot ein. Danach mounten wir das logische Volume mit dem alten MongoDb-Stand in das Verzeichnis /srv/mongodb, wo das Betriebssystem die MongoDb-Isntanz vermutet. Beachten Sie, dass wir die Größe für das neue logische Volume mit einem 1G gmessen haben, obwohl der snapshot selbst 100MB groß ist. Das ist der tatsache geschuldet, dass ein Snapshot ja nur die Änderungen seit dem letzten Snapshot enthält und die Gesamtgröße der Datenbank ja größer ist als der Snapshot selbst.  die größe des logischen Volumes sollte immer so groß sein, wie die MongoDB zum Zeitpunkt des Snapshots tatsächlich war. Zum Zeitpunkt als wir den Snapshot mit einer größe von 100 BM gemacht haben war das MongoDB-Verzeichnis also hchstens 1 GB groß, ansonsten wäre die Größe zu klein und der snapshot könnte nicht sauber zurückgespielt werden.

Wenn Sie den Snapshto nicht in ein .gz-File komprimieren, sondern direkt vom logischen Volume des sanpshots zurückgehen wollen, ginge das so

umount /dev/vg0/mdb-snap01

lvcreate --size 1G --name mdb-new vg0

dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new

mount /dev/vg0/mdb-new /srv/monogdb

 

 

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!