User:Bourke/Knothuebergabe

Admin

Pubman Sicherung
mount-points: /dev/x/v            /X --> fedora live-daten auf SAN /dev/mapper/x-v       5.8T  1.5T  4.1T  26% /X /dev/y/v            /Y  --> kopie, gesyncht alle 2 stunden       /dev/mapper/y-v       5.8T  1.5T  4.1T  27% /Y --> kopie-job läuft dauernd unter /bin/bash /root/bin/rsync.SRV01.XY /dev/p/v          /P --> postgres live-daten /dev/mapper/p-v       867G  214G  609G  26% /P /dev/q/v          /Q --> postgres sicherung Ziel: alle 2 stunden kopieren./dev/mapper/q-v       867G  299G  524G  37% /Q

postgres sicherung

 * 1) per crontab 1:59 /root/bin/Postgres-Backup.sh --> /X/backup/srv01/pgsql/backup gepackt
 * 2) Unter /Q (momentan per hand erzeugt, wenn Postgres unten ist.

Wiederherstellung

 * 1) rsync.SRV01.XY  läuft? Laufen lassen und abwarten.(ansonsten inkonsistente Fedora Datastream (SuperGAU) Dateien landen unter:
 * 2) fedora: /Y/fedora3.3
 * 3) lucene indexes ebenso alle 2 stunden gesichert: normalerweise schnell (es sei den: reindex im letzten tag. Sicherung ist unter srv01 /X/backup/srv02/jboss/server/default/data
 * 4) Ausgang: Fedora Daten sind vorhanden.

Wiederherstellung pgsql
restore_command = '/bin/cp /X/backup/srv01/pgsql/logs %f %p' restore_target_time = 'timeoflastwriteoffedoraitem or lucene index'
 * 1)  Postgresql "point-in-time" Sicherung von /X/backup/srv01/pgsq (am Aktuellsten) oder /Y (alle 2 stunden von /X) oder /Q (am Ältesten, nur manuell in heruntergefahren Zustand erzeugt) zurückholen
 * 2) pg-cluster  stoppen
 * 3) pg live data-verzeichnis wegmoven, falls Platz reicht
 * 4) entpacken von  /X/backup/srv01/pgsql/backup ins Data-Verzeichnis
 * 5) recovery.conf erstellen im Data-Verzeichnis beispiel

Wiederherstellung anhand Fedora-Daten
XEventuell von der letzen Sicherung unter /Y kopieren. Coreservice muss unten sein.
 * 1) Ist postgres noch verfügbar? (Daten unter /P)
 * 2) wann wurde die letzte fedora-Daten geschrieben unter /X (live) und /Y (sicherung)?
 * 3) z.Bs find . -mtime -1|head -8
 * 4) vor dem fedora rebuild müssen postgres dbs fedora3 und ritriples geleert und neu erstellt werden.
 * 5) (drop database / create database auf beiden)
 * 6) |Fedora rebuild 2x aufrufen (1 fedora-db, 2 riTriples). Dauer: 3 stunden.
 * 7) escidoc coreservice hochfahren auf srv02
 * 8) login admin-console und rebuild reindex anstossen. (Dauer

Jira
im zweifelsfall: natasa fragen

VPN / Infrastruktur
http://doku/mediawiki/index.php/VPN#Installation_unter_Linux.2FMac
 * 1) auf laptop ubuntu 10.04 LTS downgrade machen, danach

mediawiki upgrade
CSS manuelle migration üben.

sources of errors: differences in skins / css content, apache config may contain some references to edoc0 still