====== Administration der Oracle NoSQL Database 11gR2 - Backup und Recovery  ======

Oft wird in der NoSQL Welt das Thema Backup sehr stiefmütterlich behandelt, mit der Begründung „bei genügend Server Knoten kann ja bei einem Ausfall nichts passieren“, das Problem mit logischen Fehlern wird kaum beachtet. Mit der Oracle NoSQL aber lassen sich Snapshots des gesamten Stores erzeugen. Auf Basis dieser über alle Knoten konsistenten Snapshots kann ein echtes Backup Konzept realisierbar wird. Die Daten in einem Snapshot können auch in einen anderen Store wieder importiert werden, zum Bespiel um eine Testumgebung aus den Produktionsdaten aufzusetzen.



Die Verwaltung der Umgebung erfolgt über das Kommandozeilen Werkzeug.


Aufruf mit:

<code bash>

java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host $HOSTNAME

</code>

==== Backup des Store ====

Mit Hilfe des Snapshot Kommando (snapshot create -name <snapshot name>) wird über den gesamten Store (d.h. über alle Knoten und alle Master und Replikas) ein Snapshot der Daten erzeugt.

Ablauf einer Sicherung:
  * Snapshot erzeugen
  * Daten von $KVROOT/<store_mame>/<SN>/<resource>/snapshots/<snapshot_name>/files sichern auf ALLEN Knoten sichern
    * im Prinzip würden auch jeweilige Master auf den Knoten ausreichen.
  * Snapshot löschen

Beispiel:
<code bash>

# Anlegen
kv-> snapshot create -name freitag_14_06_2013
Created snapshot named 130614-123305-freitag_14_06_2013

# Was für Snapshots existieren
kv-> show snapshot

#Löschen
kv-> snapshot remove -name 130614-123305-freitag_14_06_2013
Removed snapshot 130614-123305-freitag_14_06_2013 

</code>

=== Konfiguration eines SN sichern ===

Fällt die Hardware eines SN komplett aus, ist es hilfreich eine Sicherungskopie der SN Konfiguration des Nodes  zuvor erstellt zu haben.

Befehl:
<code bash>
java -jar KVHOME/lib/kvstore.jar generateconfig -host $HOSTNAME -port 5000 -sn sn1 -target ~/sn1.config
</code>

Mit der erzeugen Datei, in unseren Beispiel "sn1.config.zip", kann eine neuer Node mit gleicher IP Adresse, gleichen Namen und gleicher Storage Konfiguration wieder neu initialisiert werden.


Ablauf um einen kompletten Node wieder neu anzulegen:
  * Neuen Host gleich wie alten Host konfigurieren (IP/Name/Storage/Gruppen/User/Recht etc.)
  * Auf den neuen Host $KVROOT anlegen
  * Zip File aus dem Config Backup auf den neuen host in $KVROOT auspacken
  * SN neu starten





===== Restore eines Stores =====

Für den Restore stehen zwei Möglichkeiten zur Verfügung, den Snapshot direkt wieder einspielen oder die Daten erneut laden.

====Snapshot direkt wieder einspielen====

Die Topologie hat sich nicht verändert d.h. alle Knoten sind unverändert konfiguriert und online!
Nur dann lassen die direkt die Snapshots wieder einspielen!


Ablauf:

  * Verzeichnis restore anlegen in $KVROOT/<store_name>/<sn node>/<replikat_nr>-<sn node>/recovery
  * Snapshot in das Recovery Verzeichnis verschieben auf dem der passende Storage Node läuft
  * Storage Node neu starten, beim Start erkennt der Node die Snapshot Dateien zum Recovery

=== Test 1 - Restore eines Nodes ===

Beispiel:

<code bash>
# Verzeichnis anlegen
mkdir $KVROOT/GPIDB/sn1/rg1-rn1/recovery

#snapshot daten dahin verschieben
mv  $KVROOT/GPIDB/sn1/rg1-rn1/snapshost/130614-142350-freitag/ $KVROOT/GPIDB/sn1/rg1-rn1/recovery


# Service stoppen
java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT

# Starten
nohup java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT & 

</code>


Ein erster Test war allerdings nicht so recht erfolgreich, der Store ließ sich so nicht wirklich wieder zurücksetzen, evtl. nützlich bei größeren Datenmengen um einen Master Teil wieder herzustellen?


=== Test 2 - gesamten Store zurücksetzen ===

Ablauf:
  * Snapshot angelegt
  * Daten im Store "ausversehen .-)" gelöscht
  * Store komplett gestoppt
  * alle Recovery Verzeichnisse auf allen Knoten auf Snapshot verlinkt
  * Store wieder gestartet 

Im zweiten Test wird auf allen Knoten in den SN Verzeichnissen recovery auf das snapshot Verzeichnis gelinkt um  beim Neustart der Knoten die alten Daten wieder einzulesen.


<code bash>
# Admin Konsole starten
java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host $HOSTNAME

# Snapshot anlegen
kv-> snapshot create -name sonntag
Created snapshot named 130616-183718-sonntag on all 10 nodes

# Sequence Nummer aus Ping merken:
java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldb01
#wie
        Rep Node [rg1-rn3]      Status: RUNNING,REPLICA at sequence number: 1,612,835 haPort: 5010
        Rep Node [rg2-rn3]      Status: RUNNING,REPLICA at sequence number: 1,620,315 haPort: 5011
        Rep Node [rg3-rn3]      Status: RUNNING,MASTER  at sequence number: 1,619,967 haPort: 5012


# Daten über Testprogramm löschen

# Auf allen Knoten Store stoppen
java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT


# Auf allen Knoten!!
# wie hier auf 1!
cd $KVROOT/GPIDB/sn1/rg1-rn1
ln -s snapshots/ recovery
cd $KVROOT/GPIDB/sn1/rg2-rn1
ln -s snapshots/ recovery
cd $KVROOT/GPIDB/sn1/rg3-rn1
ln -s snapshots/ recovery

# Auf allen Knoten die Dienste neu starten
nohup java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &

# Warten bis Store wieder online
java -jar $KVHOME/lib/kvstore.jar ping -port 5000 -host nosqldb01

# Sequence Nummer sind nun zurück gesetzt:

        Rep Node [rg1-rn3]      Status: RUNNING,REPLICA at sequence number: 1,609,571 haPort: 5010
        Rep Node [rg2-rn3]      Status: RUNNING,REPLICA at sequence number: 1,616,853 haPort: 5011
        Rep Node [rg3-rn3]      Status: RUNNING,MASTER at sequence number: 1,616,701 haPort: 5012


# Anzahl der Daten im Store mit Testprogramm prüfen:
# > Daten sind wieder da!

# alle Recovery Links wieder entfernen
cd $KVROOT/GPIDB/sn1/rg1-rn1
unlink recovery
#usw.  (darauf achten das beim unlink  Befehlt kein / am Ende steht .-) !!!

</code>

Mit diesem Ablauf ließ sich der Store wieder komplett auf den Snapshot Punkt zurücksetzen.

**!!Achtung!!** \\
!!Der Snapshot wird mit dieser Methode automatisch gelöscht!!

=== Quelle ===

siehe Doku : http://docs.oracle.com/cd/NOSQL/html/AdminGuide/recovery.html#restoredirect

==== 3. Daten wieder einspielen ====

Mit dem Lade Programm "oracle.kv.util.Load" kann ein Snapshot auch wieder in die Datenbank geladen werden.


Verwendung:
<code>
java -jar KVHOME/lib/kvstore.jar load 
     -source <backupDir> 
     -store <storeName> 
     -host <hostname> 
     -port <port> 
     [-status <pathToFile>]
     [-verbose] 
</code>

Parameter:

  *  -source <backupDir> Verzeichnis mit dem Snapshot
  *  -store <storeName> Name des Stores
  *  -host <hostname> Node für das Einlesen 
  *  -port <port> Port des SN auf dem Node
  *  -status <pathToFile> Status File anlegen, mit Hilfe des Status Files kann bei einem Fehler wieder an gesetzt werden

Beispiel:



<code bash>

java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg1-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000

Load succeeded, wrote 2818 records


java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg2-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000

Load succeeded, wrote 2902 records


java -jar $KVHOME/lib/kvstore.jar load -source $KVROOT/GPIDB/sn1/rg3-rn1/snapshots/130616-212153-sonntag -store GPIDB -host $HOSTNAME -port 5000

Load succeeded, wrote 2780 records


</code>

Nach dem laden ALLER Snapshots der drei SN sind ALLE Daten wieder da. \\
Alle Daten werden geladen und für existierende Schlüssel die Values überschrieben.


=== Quelle ===

http://docs.oracle.com/cd/NOSQL/html/AdminGuide/recovery.html#usingload