Backupmöglichkeiten im laufenden Betrieb

[formtapez]

Hallo !

Ich habe einen root-Server mit Debian 3.0 in einem Rechenzentrum stehen und suche nun nach einer Möglichkeit ein Backup zu machen.
Das ich den Rechner nicht einfach runterfahren kann, um ein komplettes HDD-Image zu ziehen, dürfte ja klar sein.
Was gibt es da sonst noch für Möglichkeiten ?


MfG
formtapez

[xstevex22]

Hi!
Mittels rsync oder tar (wenn noch genug Platz ist auf der Platte).

[netzmeister]

Hallo,

wir bieten unseren Kunden die Möglichkeit der Mitbenutzung unseres Backupsystems.

So etwas solltest Du haben. Jeden Tag ein paar Gigabyte über das externe
Netz zu ziehen macht keinen Sinn.

Viele Grüße

Eicke

[formtapez]

Platz ist genug vorhanden. Auf der System-Platte, sowie auch auf anderen Servern im gleichen RZ (internes Netz ohne Kosten).

Die Frage ist nur wie ich "backuppen" soll. Gibt es nicht eine elegantere Methode die Daten zurückspielen zu können als bei der tar-Methode ?
Am liebsten wäre mir ein HDD-Image (von nur belegtem Speicherplatz) das die Admins im RZ im Notfall nur schnell zurückspielen brauchen.
Aber das wird wohl im laufenden Betrieb nicht möglich sein... oder etwa doch ? :D

MfG
formtapez

[netzmeister]

Hallo,

was wird denn in Deinen Rechenzentrum als Backuplösung eingesetzt?

Da installierst Du den passenden Client auf Deinen Server und der
Admin trägt das auf dem Server ein.

Viele Grüße

Eicke

[formtapez]

Ich möchte nicht auf die vorhandenen und teuren Backup-Server zugreifen, sondern einfach automatisch eine Backup-Archiv-Datei erstellen lassen und die per FTP, SCP oder sonstwie auf einen anderen Rechner im lokalen Netz schieben.

Ich bin eigentlich Fan von Festplatten-Image Dateien, da man dann beim zurückspielen absolut garnichts beachten braucht. Deshalb kommt für mich ein simples tar-Archiv nicht in Frage, da dann der Aufwand beim Zurückspielen einfach zu gross ist.

Ist es möglich im laufenden Betrieb ein Image zu ziehen ? Es wäre dann zwar nicht ganz konsistent aber müsste doch gehen oder ? Ich meine ich habe davon mal gelesen...

MfG
formtapez

[Windoofsklicker]

das ist alles im grunde kein problem. nur einige dateien sind im laufenden betrieb offen und können nicht gesichert werden. bei datenbanken trifft das gleiche zu. um die zu sichern musst du entweder die datenbank stoppen oder einen entsprechenden agent haben, der die datenbank live sichern kann.

du hast die möglichkeit ein tar file zu machen, musst aber damit rechnen, dass dein backup nix taucht, oder ein "richtiges" datensicherungstool einzusetzen. das ist dann allerdings selten kostenfrei.

[steve-bracket]

Original geschrieben von Windoofsklicker
das ist alles im grunde kein problem. nur einige dateien sind im laufenden betrieb offen und können nicht gesichert werden. bei datenbanken trifft das gleiche zu. um die zu sichern musst du entweder die datenbank stoppen oder einen entsprechenden agent haben, der die datenbank live sichern kann.

du hast die möglichkeit ein tar file zu machen, musst aber damit rechnen, dass dein backup nix taucht, oder ein "richtiges" datensicherungstool einzusetzen. das ist dann allerdings selten kostenfrei.

Full Ack

Datensicherung ist eine komplexe Angelegenheit, die, wenn's mal läuft zwar möglichst im Hintergrund und ohne viel Aufwand (wie ne versicherung) funktionieren soll, und im Schadensfall einspringt.
Aber sowas gehört vernünftig ausgearbeitet, und wie Windoofsklicker schon bemerkt hat, im laufenden Betrieb kommst du wohl nicht um kommerzielle Programme herum.

Zumindest nach meiner Erfahrung, falls jemand was gegenteiliges weiß oder zu Wissen glaubt, raus mit der Sprache.

Gruß

[Svenny]

Ich habs so gelöst, zwar noch ausbaufähig aber es tut ;)




#!/bin/bash

# Backup Script (c) 2004 Sven Sager [sven@sve-sa.de]
TIMESTAMP=$(date +"%Y%m%e-%H%M%S")

echo "Starting Backup on $TIMESTAMP"
echo "Disk Usage before Backup:"

# Mount Backup Drive #
mount -t ext3 /dev/hdb5 /backup

df -k /backup

# Create Backup Folder #
mkdir -m 700 /backup/backup-svesa1/$TIMESTAMP

TODIR="/backup/backup-svesa1/$TIMESTAMP"

rsync -ca /etc $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-etc.tar.gz $TODIR/etc
rm -rf $TODIR/etc

rsync -ca /home $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-home.tar.gz $TODIR/home
rm -rf $TODIR/home

rsync -ca /root $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-root.tar.gz $TODIR/root
rm -rf $TODIR/root

rsync -ca /var/www $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-www.tar.gz $TODIR/www
rm -rf $TODIR/www

rsync -ca /var/cache/bind $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-bind.tar.gz $TODIR/bind
rm -rf $TODIR/bind

rsync -ca /var/cache/awstats $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-awstats.tar.gz $TODIR/awstats
rm -rf $TODIR/awstats

rsync -ca /var/lib/mysql $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-mysql.tar.gz $TODIR/mysql
rm -rf $TODIR/mysql

rsync -ca /var/log $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-log.tar.gz $TODIR/log
rm -rf $TODIR/log

rsync -ca /usr/src $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-src.tar.gz $TODIR/src
rm -rf $TODIR/src

rsync -ca /var/mail $TODIR
/bin/tar czf $TODIR/$TIMESTAMP-mail.tar.gz $TODIR/mail
rm -rf $TODIR/mail



echo "Disk Usage after Backup:"
df -k /backup

umount /dev/hdb5

echo "Backup Finished $(date +"%Y%m%e-%H%M%S")"

[Jasper]

Original geschrieben von steve-bracket

Zumindest nach meiner Erfahrung, falls jemand was gegenteiliges weiß oder zu Wissen glaubt, raus mit der Sprache.



wie hier bereits angesprochen sind die offenen files ein problem. eine sehr gute und sichere methode ist die verwendung von snapshots (hatte ich hier kürzlich etwas dazu geschrieben):

mal am beispiel von XFS erklärt, geht aber mit jedem snapshotfähigen filesystem:

1. einfrieren des filesystems mit xfs_freeze, dabei werden alle offenen schreiboperationen abgeschlossen, neue schreiboperationen werden angehalten; jetzt ist das filesystem in einem konsistenten zustand.

2. erstellen eines snaphotvolumes mit lvcreate, das snaphotvolume spiegelt genau den (konsistenten) zustand wieder, den das filesystem zu diesem zeitpunkt hat

3. auftauen des filesystems mit xfs_freeze, alle schreiboperationen sind wieder zugelassen.

4. backup des snapshots (entweder mounten oder mit dd)

5. löschen des snapshotvolumes mit lvremove


das ganze klingt vielleicht kompliziert ist es aber nicht.


-j

[cane]

@ Jasper

Sehr interessant. Funktioniert der Freeze des Filesystems bei anderen gängigen (ext2, ext3, ReiserFS) Filesystems?

mfg
cane

[Jasper]

Original geschrieben von cane
Sehr interessant. Funktioniert der Freeze des Filesystems bei anderen gängigen (ext2, ext3, ReiserFS) Filesystems?


ext3 mit lvm-VFS-lock.patch: ja.
ext2 und reiser weiss ich nicht (jemand hatte behauptet, reiser hätte auch snapshots, auf nachfrage kam aber nichts).


-j

[Windoofsklicker]

@jasper

wo bitte ist denn der unterschied, das filesystem zu freezen oder die datenbank anzuhalten? kann man im zustand des eingefr. filesystems weiterarbeiten? finden schreiboperationen dann quasivirtuel im speicher statt?

[Jasper]

Original geschrieben von Windoofsklicker

wo bitte ist denn der unterschied, das filesystem zu freezen oder die datenbank anzuhalten? kann man im zustand des eingefr. filesystems weiterarbeiten? finden schreiboperationen dann quasivirtuel im speicher statt?

nein, sämtliche schreiboperationen werden angehalten. das anlegen des snapshots dauert nur ein paar sekunden, danach kann weitergeschrieben werden. die unterbrechung ist damit minimal. bei datenbanken hängt es von der datenbank ab, ob ein filesystemfreeze ausreicht. gute datenbanken haben einen sogenannten quiesce-modus (entspricht einem anhalten der datenbank), der im grunde das gleiche macht wie der filesystem-freeze. es werden alle offenen transaktionen abgeschlossen, neue transaktionen werden auf "hold" gesetzt.

der vorteil der snapshots ist, dass man damit ein konsistentes backup hat und dass das die backupdauer keine rolle mehr spielt. mehrere hundert GB an daten zu sichern dauert, egal wie schnell das sicherungsmedium ist. grosse datenbestände werden AFAIK immer per snapshot gesichert, entweder über einen volumemanager (beste variante) oder per split-mirror (hat den nachteil, dass danach ein resync erfolgen muss).


-j

[formtapez]

Ist es auch möglich das man das snapshot per Netzwerk sichert, so das man keine zweite Festplatte benötigt ?

MfG
formtapez

[Jasper]

Original geschrieben von formtapez
Ist es auch möglich das man das snapshot per Netzwerk sichert, so das man keine zweite Festplatte benötigt ?


der snapshot braucht physikalischen platz. wieviel hängt davon ab, wieviel änderungen anfallen und wie lange der snapshot benötigt wird.

viele änderungen und lange backupzeit = hoher platzbedarf.

als faustregel gilt: 15-20% vom originalvolume. es muss keine zweite festplatte sein, da der platz sowieso von einer volumegroup bezogen wird. wie sich die volumegroup zusammensetzt (eine grosse festplatte oder mehere kleine) ist für den snapshot egal.


-j