Review ZFS Backup Script

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Fri, 29 Mar 2013 23:45:41 +0100
Hallo ZFS-Freaks,

ich bastel gerade an einem auf ZFS Snapshots basierendem Backup für den
Vereinsserver. Da ich noch nicht arg viel Erfahrung mit ZFS habe,
benötige ich mal euer Feedback dazu:

== Das Script ==
.........|.........|.........|.........|.........|.........|.........|..
#! /bin/sh

set -x

NOW="$(date +%Y%m%d%H%M%S)"
FS=zroot/home

SRC="${FS}"
DST="tank/backup/uugrn.org/top3/${FS}@${NOW}"

OLD="${SRC}@backup_old"

# snapshot last successfull backup
CURRENT="${SRC}@backup_current"

# create working snapshot (NOW!)
# zroot/home_at_backup_working_YYYYMMDDHHMMSS
WORK="${SRC}@backup_working_${NOW}"
zfs snapshot "${WORK}"

# send incremental snapshot to destination
zfs send -i "${CURRENT}" "${WORK}" |
        buffer -m 20m |
                zfs receive -F "${DST}" &&
(
        zfs destroy "${OLD}" ;                   # @backup_old
        zfs rename -r "${CURRENT}" "${OLD}" &&   # @backup_current --> @backup_old
        zfs rename "${WORK}" "${CURRENT}"        # @backup_work* --> @backup_current
)
.........|.........|.........|.........|.........|.........|.........|..


== Das Ergebnis ==
Wenn das Script erfolgreich (paarmal) durchgelaufen ist, dann ergibt das 
folgende Snapshots:

[root_at_top3 ~]# zfs list -Ht snapshot | grep home | awk '{print $1;}'
tank/backup/uugrn.org/top3/zroot/home_at_20130329222410
tank/backup/uugrn.org/top3/zroot/home_at_20130329223631
tank/backup/uugrn.org/top3/zroot/home_at_20130329223759
tank/backup/uugrn.org/top3/zroot/home_at_20130329223834
tank/backup/uugrn.org/top3/zroot/home_at_20130329230014
tank/backup/uugrn.org/top3/zroot/home_at_20130329230912
tank/backup/uugrn.org/top3/zroot/home_at_20130329231022
zroot/home_at_backup_old
zroot/home_at_backup_current

== Was noch fehlt ==
Was das Script bisher nicht kann: Prüfen, ob zroot/home_at_backup_current
existiert und falls nicht einen initialen snapshot erzeugen und
nicht-inkrementell (zfs send ohne "-i") nach
tank/backup/uugrn.org/top3/zroot/home_at_YYYYMMDDHHMMSS zu schieben und
bei Erfolg diesen nicht-inkrementellen snapshot dann umbennen nach
zroot/home_at_backup_current

== Meine Strategie ==

1) An der Quelle (zroot/*) werden zu Backup-Zwecken nur maximal 2 Snapshots
rollierend angelegt (current, old) und langfristig aufbewahrt, ich erspare 
mir eine Löschtaktik und irgendwelche Script-Konstrukte auf Timestamp-Snapshots.

2) Am Ziel (tank/backup/uugrn.org/top3/zroot/) bekomm ich diese
Snapshots archiviert, es werden (vorerst) keine alten Snapshots
gelöscht (wenn hier der Platz eng wird muss ich mir was ausdenken)

3a) Im Falle eines Full-Restore  würde ich den erforderlichen Stand zB
tank/backup/uugrn.org/top3/zroot/home_at_20130329230912 kopieren nach
zroot/home_at_20130329230912 und anschließend ein "zfs rollback" auf diesen
Snapshot ausführen.

3b) Im Falle eines partiellen restores würde ich die erforderlichen Dateien 
einfach per rsync oder sonstwie kopieren von tank/home nach zroot/home.

== Fragen ==

1) Kann ich irgendwie innerhalb von ZFS an zroot/home_at_backup_current
eine Freitext-Information einfügen, in der
tank/backup/uugrn.org/top3/zroot/home_at_20130329231022 steht? Damit wäre
es möglich zu den nicht-historisierten Snapshots (current, old) den
jeweiigen Historisierungs-Stand zu "merken": 

Q: Wohin wurde das letzte Backup geschrieben? 
A: zroot/home_at_backup_current::Freitext-Property
Q: Wohin das Backup davor?
A: zroot/home_at_backup_old::Freitext-Property

Bitte mit Beispiel.

2) Was ist das *sinnvollste* Command um die Existenz eines Snapshots (zB
zroot/home_at_backup_current) zu prüfen? zfs get? Ich benötige das um zu
erkennen, ob "zfs send" inkrementell erfolgen kann oder nicht.

3) Hier geht es erstmal darum, zroot nach tank/backup zu sichern,
Traffic spielt hier kaum eine Rolle (lokale pipes). Allerdings sollen
die Snapshots auch auf andere Server überrtagen werden (via ssh). Wie 
kann ich *vor* einem "zfs send" ermitteln, wieviele Daten (in MBytes/GBytes) 
übertragen werden? 
Ich will hier eine Sollbruchstelle einbauen, dass eine remote-Sicherung
von Snapshots nur dann automatisiert erfolgt, wenn die Datenmenge nicht
zu groß ist.

== Kritik erwünscht ==

* Gibt es prinzipiell bessere Methoden, Best practises?
* Wird mein Konstrukt irgendwann vor die Wand laufen? 
  + mit welchen Auswirkungen?
* Könnte mein Konstrukt wie oben einen Restore gefährden?

Danke und Gruß
Raphael

-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyter@gmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..


-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 29.03.2013

Dieses Archiv wurde generiert von hypermail 2.2.0 : 29.03.2013 CET