Frage zu restore

sterum

Well-Known Member
Mahlzeit Forum,

Kann ich ein Backup eines Filesystems welches mit dump angelegt wird eigentlich auf eine größere Partition zurücksichern oder muß sie zwingend die selbe Größe haben?
 
Problemlos möglich.... Im Prinzip "entpackst" du mir restore das "dump-archiv". Da du ja nur die Daten sicherst und nicht (wie z.B. mit dd) die Partitionen ist das losgelöst. Theoretisch kannst du sogar die Partitionierung komplett umstellen.
 
restore kann sogar auf anderen Dateisystemen wiederherstellen.
 
Danke, sehr gut. Dann kann ich mir jetzt Gedanken über ein "richtiges" Backup mit dump und restore machen.
Denn das synchronisieren von Verzeichnissen ist kein Backup, wie ich gestern feststellen mußte. Ist zwar nur ein Foto, aber weg ist weg. :ugly:

Mal überlegen was ich jetzt für eine Strategie wähle...
 
das verstehe ich nicht, könntet ihr mir das erklären?

Ich versteh, dass es einen Unterschied zwischen einem Backup und einer Kopie gibt. Auch, dass ein Sync nur eine Art Kopie und kein Backup darstellt.
Aber alles sichert mir alle Daten zu einem gewissen Zeitpunkt.
Zu einem anderen Zeitpunkt gibt es immer Unterschiede und deshalb möglichen Datenverlust gegenüber der aktuellen Version. Nur ein Raid kann helfen, Daten nicht zu verlieren. Ein Backup kann genauso verlustreich sein, wie ein Sync.
Oder?
 
Nicht ganz... Ein RAID schützt dich ausschließlich vor Hardwareversagen. Zerreißt es dir dein Dateisystem oder es dreht ein Prozess durch der Daten löscht/ändert ist der komplette RAID betroffen. Ebenso ein versehentliches Löschen wird den kompletten RAID ansprechen. Ein RAID ist daher NIE ein Ersatz für ein Backup.

Ein Sync hat da ähnliche Probleme: Dir gehen Daten verschüttet (weil du sie z.B. versehentlich gelöscht hast) und dein Sync löscht munter die Kopie auf deinem vermeintlichen "Backup". Bist du also genauso Nass....

Eine vernünftige Backupstrategie sieht z.B. inkrementelle Backups vor. Das heisst du hast mit relativ wenig "Backupspace" eine gewisse Historie. Jetzt geht dir heute eine Datei "verloren" und morgen läuft dein Backup. Übermorgen suchst du die Datei... Beim Sync wäre sie nun im Nirvana... Machst du inkrementelle Backups kannst du einfach das Backup von gestern holen und die Datei raus ziehen (selbst wenn in deinem aktuellsten Backup diese bereits fehlt). Wie du vermuten kannst ist hier eben die Strategie wie du die Backups anlegst maßgeblich für die Datensicherheit.
 
verstanden.

Das raid wollte ichnicht als Ersatz für ein Backup vorschlagen, schon zusätzlich zu einem.
Was ich nicht bedachte, war die Möglichkeit, diese "inkrementellen" Backups zu machen.
Ich sah nicht weit genug, dachte nur an ein Backup und wollte nicht den Unterschied zu Sync erkennen.
So ist es nun auch mir klar, was ihr meint.

Danke.
 
Naja, eine einfache Kopie kann durchaus als Backup dienen und je nach Anwender ausreichend sein.
 
Seit einer Woche mach ich meine Backups nach dieser Anleitung http://www.denkrobat.de/wiki/index.php/Backup_des_Systems
Halt an meine Gegebenheiten angepasst.

Funktioniert soweit auch wunderbar. Jedoch würde mir ein Skript das mit KDE4 spricht besser gefallen. Wie ich gesehen habe gibt es seit KDE4.8 die kdebindings4-perl-perlkde in den Ports. Vielleicht läßt sich da was zusammenschustern das zumindest mit dem Systray spricht. Ein paar Meldungen wann ein Backup gestartet oder beendet wird wären halt schön. :)
 
Hi Sterum!

Verwendest du das http://www.denkrobat.de/wiki/index.php/Backupscript oder hast du Einzelscripte am Laufen? Das Backupscript wollte ich eh irgendwann nochmal überarbeiten, aber falls du paar Erweiterungen einbaust die das Ganze allgemein komfortabler machen wäre es nett wenn du mir die Anpassungen wieder zukommen lassen würdest :) Dann würde ich die im Wiki auch einpflegen.

(Idealerweise dann halt etwas modular aufgebaut, da ich z.B. gar kein KDE verwende ;D )
 
Ich wurde freundlicherweise darauf hingewiesen, dass das Script auf dump aufsetzt und daher mit Journaling Softupdates derzeit NICHT verwendet werden sollte!! Ich erwähne es hier nur nochmal kurz bevor sich jemand versehentlich sein System zerballert. Eine entsprechender Warnhinweis wurde im Wiki ergänzt!
 
Ich hab die Einzelskripte am laufen. Das Backupskript schiebt ja die Backups in einen Mountpoint, Ich hingegen schreibe die Backups via ssh an einen entfernten Rechner.
Code:
/sbin/dump -$LEVEL -h 0 -Lauf - /dev/ada0p4 | ssh sterum@pluto dd of=/usr/data/root-ada0p4_$DATUM-L$LEVEL
Da ich zu Faul war das Skript anzupassen hab ich mich für die Einzelskripte entschieden.
Evtl. überleg ich mir was ohne (ana)cron, da hier das Problem besteht, das im schlechtesten Fall ein Level 2, 1 und 0 Backup am selben Tag gemacht wird, was ja pure Speicherplatzverschwendung ist :)
Außerdem könnte man eine Möglichkeit schaffen nicht mehr benötigte (ältere) Backups automatisch zu löschen.

[edit]
Zur Zeit ist das Wetter zu schön um daran zu Arbeiten :)
[/edit]
 
Hmm... per SSH ist auch ne interessante Idee.... Das könnte ich mir mal überlegen mit rein zu packen. :)
Dass die Levels zusammenfallen hast du auch mit normalem Cron. Da du ja aber ein komplettes Level 0 stehen hast auf welches er dann das 1 und 2 aufsetzt sind diese "eher klein".

Ja die alten lösche ich derzeit von Hand... Aber das nervt mich auch ein wenig... Da müsste man mal überlegen wie ich das besser machen kann...

Kommt Regen, kommt Update ;)
 
Ich hab jetzt ein Perl Modul geschrieben, das die Funktion dumplevel() enthält. Man kann damit den nächsten benötigten Dumplevel ermitteln und im Backupskript verwenden. Das Backupskript wird dann ohne weiteres Argument von /etc/periodic aufgerufen (täglich). Oder auch von irgendeiner Autostartfunktion. Dadurch wird an einem Tag wirklich nur der benötigte (L0, L1, oder L2) Dump durchgeführt.
[edit] Man könnte das Backupskript so umgestalten, das man ihm entweder als Parameter den Dumplevel von Hand übergibt (so wie bisher) oder wenn es ohne Parameter aufgerufen wird, wird eben meine Funktion verwendet. [/edit]

Code:
perldoc Dumplevel
im Modulverzeichnis ausführen für nähere Informationen.


Das Modul liegt idealerweise im selben Verzeichnis wie das Backupskript.

Ein Beispielprogramm habe ich auch hochgeladen.
 

Anhänge

  • Dumplevel-0.1.pm.zip
    1,2 KB · Aufrufe: 175
  • use_dumplevel.pl.zip
    317 Bytes · Aufrufe: 184
Shit, hab einen Fehler entdeckt. Hier mal eine aktuelle Version.
 

Anhänge

  • Dumplevel-0.2.pm.zip
    1,2 KB · Aufrufe: 176
Nochmals eine aktualisierte Version.

Die Parameter werden nun überprüft.
Wenn noch kein dump nötig ist gibt die Funktion nun 'undef' zurück.
Die Mustererkennung hab ich auch etwas verbessert.
Und noch ein paar Schönheitskorrekturen.
 

Anhänge

  • Dumplevel-0.3.zip
    1,5 KB · Aufrufe: 168
  • use_dumplevel-0.3.pl.zip
    339 Bytes · Aufrufe: 179
Für das grafische Feedback meines Backupskripts in KDE hab ich mich nun für das Perl Modul Desktop::Notify entschieden.

http://search.cpan.org/~sacavilia/Desktop-Notify-0.03/lib/Desktop/Notify.pm

Das ganze setzt auf DBus auf und sollte somit auch mit Gnome, XFCE und Enlightenment funktionieren. Ob diverse Windowmanager auch eine Benachrichtigungsfunktion mitbringen weiß ich aber nicht.

Das Modul ist nicht in den Ports, läßt sich aber problemlos installieren.
 
Zurück
Oben