Tag: Backup

Posted on

Syncany: Dropbox-Alternative für die Datensicherung in der Cloud

syncany-logoDa habe ich eben noch von der klassischen Sicherung auf externe Datenträger geschrieben und natürlich gibt es noch die Möglichkeit alles Wichtige wie Fotos, Urkunden, Krankenakten und Versicherungspolicen säuberlich eingescannt und für jeden einsehbar in der ominösen Cloud abzuspeichern. Warum nicht einfach beides nutzen? Doch macht das alles wirklich Sinn und welche Alternativen gibt es?
Anfang des Jahrzehnts nutzte ich für eine Weile Dropbox, weil es für mich ein einfacher Weg war, um Dateien an andere Leute freizugeben. Gleichzeitig hatte ich einen kostenlosen Datenspeicher und eine weitere Backupmöglichkeit gefunden. Irgendwann hatte ich dann meinen eigenen vServer, weswegen ich den Dienst nicht mehr brauchte. Vor einigen Tagen erhielt ich nun die Nachricht, dass mein Dropbox-Konto in 90 Tagen geschlossen werden sollte, weswegen ich das kurzerhand und als Motivation für diesen Artikel selbst erledigt habe.
Es gibt mittlerweile zahlreiche Freie-Software-Alternativen zu Dropbox, wobei OwnCloud,  Seafile und SparkleShare sicherlich drei der bekanntesten sind. Mit diesem Artikel möchte ich Syncany kurz vorstellen, dass ich letztes Jahr für Debian paketiert habe. Die Software ist in Java geschrieben und gegenüber Dropbox zeichnet sich dieses Programm vor allem durch zwei Merkmale aus:

  • Lokale Verschlüsselung der Daten vor dem Upload
  • Nahezu beliebige Wahl des externen Datenspeichers durch ein Pluginsystem

Der erste Punkt ist für mich persönlich der wichtigste, warum ich Anwendungen wie Syncany Dropbox vorziehe. Es ist Freie Software, transparent und man hat volle Kontrolle bevor man die Daten irgendwohin hochlädt. Zwar werden Dateien auch bei Dropbox verschlüsselt auf den Servern gespeichert, jedoch besitzt das Unternehmen auch den Schlüssel, um die Informationen wieder im Klartext anzuzeigen, sprich sensible Daten könnten ohne weiteres eingesehen werden. Syncany hingegen verschlüsselt die Dateien auf dem eigenen Rechner vor dem Upload.
Das Programm lässt sich sowohl mit einem GUI-Plugin als auch über die Kommandozeile bedienen und liefert dazu noch eine ausführliche Online-Dokumentation, mehrere Manpages und Beispiele. Bevor ich nun aber mein persönliches Setup vorstelle, hier eine ausdrückliche Warnung: Syncany ist noch Alpha-Software. Das bedeutet ihr solltet kritische Daten noch auf eine andere Weise gesichert haben, bevor ihr sie Syncany anvertraut.

Syncany und das SFTP-Plugin

Syncany lässt sich zur Zeit über Debian Experimental installieren, wo es vermutlich eine Weile bleiben wird, da die Entwicklung seit Ende letzten Jahres sich deutlich verlangsamt hat und der Hauptentwickler gebeten hat diese Version nicht für eine stabile Debian/Ubuntu-Distribution betreuen zu müssen. Installieren lässt sie sich dennoch ganz einfach mit
apt install syncany -t experimental
Mit sy plugin list erhaltet ihr eine Übersicht aller zur Verfügung stehenden Plugins. Sobald Syncany für stabil erklärt wurde, plane ich zumindest das GUI- und SFTP-Plugin für Debian zu paketieren. Zur weiteren Verfügung stehen momentan Plugins für: Azure, Dropbox, Flickr, FTP, Raid0, Amazon S3, Samba, Openstack Swift und Webdav.
Das SFTP-Plugin wird mit sy plugin install sftp installiert und findet sich danach in ~/.config/syncany/plugins/lib wieder.
Ladet zuerst euren öffentlichen SSH-Schlüssel zum SSH-Server hoch, z.b. mit ssh-copy-id. Wechselt danach in das Verzeichnis, dass in Zukunft mit dem SFTP-Server synchronisiert werden soll und gebt nacheinander das Folgende ein:

  • sy init
  • sftp
  • Name des Hosts oder die IP-Adresse
  • Name des Benutzers auf dem Server
  • Pfad zum privaten SSH-Schlüssel
  • Password des privaten Schlüssels
  • Pfad zum Verzeichnis auf dem Server
  • Port des SSH-Servers

Das wars. Ihr könnt neue Dateien danach mit sy up hochladen.
Was bietet Syncany noch? Wie bei Dropbox könnt ihr Links zu euren Dateien mit anderen Leuten teilen. Je nach Plugin ist dieses Merkmal anders ausgearbeitet. Automatische Synchronisation gibt es mit sy daemon.

Fazit und Ausblick

Trotz des Alpha-Status ist Syncany ein nützliches Werkzeug für mich mit großem Potenzial. Das Grundkonzept ist absolut stimmig, Daten werden lokal verschlüsselt, externer Speicher kann beliebig gewählt werden. Das ist äußerst flexibel und kann an die eigenen Bedürfnisse angepasst werden. Ein funktionierendes Webfrontend wie bei Owncloud wäre natürlich noch super. Mit den jetzigen Plugins bin ich jedoch schon zufrieden. Das Hauptproblem ist momentan die geringe Entwicklungstätigkeit, weswegen Syncany vorerst nicht in Ubuntu oder einer stabilen Debianversion erscheinen wird. Wer das ändern möchte, sollte Syncany weiter testen, mögliche Fehler melden oder gegebenenfalls sogar mitentwickeln.

Posted on

luckyBackup: Die benutzerfreundliche Datensicherung mit rsync

Was Backup-Lösungen angeht halte ich es am liebsten einfach.  Rsync ist immer noch mein bevorzugtes Werkzeug für die Datensicherung und in Kombination mit Dirvish setze ich es noch heute ein, um wichtige Informationen auf meinem Laptop und dem entfernten vServer zu sichern. Nun hat rsync auch so seine Tücken. Insbesondere kann ich mir die Dutzenden von Kommandozeilenoptionen nicht alle merken und die Handhabung lässt sich schwer mit dem Wort intuitiv umschreiben. Es stellt sich immer mal wieder die Frage, ob es nun das Ziel- oder Quellverzeichnis war, das zuerst angegeben werden muss.
Für die meisten populären Kommandowerkzeuge gibt es auch eine grafische Lösung, so auch in diesem Fall mit luckyBackup. Im Prinzip ist es ein Frontend für rsync mit weiteren Annehmlichkeiten wie Sicherungsprofile mit separat einstellbaren Aufgaben, einem Zeitplaner und einer übersichtlichen Menüstruktur. Alle wesentlichen Funktionen sind hinter leicht zu findenden Schaltern und Knöpfen versteckt.

LuckyBackup

Daten sichern

Eine simple Sicherung des Dokumentenordners funktioniert wie folgt. Nach dem Klicken auf "Hinzufügen" erscheint ein neuer Dialog. Hier sollte man sich zuerst einen aussagekräftigen Namen für die Aufgabe ausdenken, z.B. "Dokumente sichern" und als Typ "Sichere Quelle innerhalb des Ziels" wählen. Danach als Quellverzeichnis den zu sichernden Ordner auswählen und den Ort, vielleicht eine externe Festplatte, wo das Ganze abgelegt werden soll. Das wars im Prinzip auch schon. Interessant ist die Möglichkeit Schnappschüsse anzulegen, hierzu gleich mehr. LuckyBackup bietet noch eine Reihe zusätzlicher Funktionen wie das Sichern zu einem entfernten Server oder das Ausschließen bestimmter Dateien von der Sicherung an. Letztere Option ist gerade dann sinnvoll, wenn man z.B. den gesamten Home-Ordner sichern möchte, jedoch auf temporäre Dateien verzichten kann. Der zweite Sicherungstyp "Synchronisiere Quelle und Ziel" ist vor allem dann nützlich, wenn man Daten häufig mit sich herumträgt und diese permanent bei allen Geräten auf den neusten Stand gebracht werden sollen. Zur reinen Datensicherung empfiehlt sich aber die Option "Sichere Quelle innerhalb des Ziels".

Aufgabendialog
Eine nützliche Option bei rsync und luckyBackup ist das Simulieren des eigentlichen Backupvorgangs. Ein gesetzter Haken bei "Simulation" reicht aus, um vorher nachzuvollziehen, ob das Programm auch das Richtige tun wird. Hat man sich Gewissheit verschafft, genügt ein Klick auf  "Ausführen", um die Datensicherung zu starten.

Schnappschüsse

Schnappschüsse

Ein weiteres nützliches Merkmal von luckyBackup ist die Sicherungsverwaltung und das Wiedereinspielen von Schnappschüssen. Im Aufgabendialog kann man festlegen wie viele Schnappschüsse vorgehalten werden sollen. Unter Aufgabe -> Verwalte Sicherung besteht nun die Möglichkeit einen älteren Schnappschuss mit dem derzeitigen Systemzustand zu vergleichen und bei Bedarf z.B. eine irrtümlich gelöschte Datei wiederherzustellen.
Möchte man sich das manuelle Sichern langfristig sparen, bietet das Programm auch die Möglichkeit die Datensicherung mit Hilfe eines Cronjobs regelmäßig auszuführen. Die Funktion versteckt sich hinter "Zeitplaner". Im Prinzip wird der tatsächlich benutzte rsync-Befehl in die crontab-Datei des Benutzers eingetragen und dann zum festgelegten Zeitpunkt ausgeführt. Im übrigen bietet luckyBackup auch immer die Möglichkeit eine solche Aufgabe vorher zu überprüfen und den rsync-Befehl direkt anzuzeigen, wodurch sich die Möglichkeit ergibt endlich die Syntax zu lernen. Die Anwendung hilft sozusagen dabei, sich selbst überflüssig zu machen.

Fazit

Ich mag luckyBackup, weil es einfach gestaltet ist und die komplizierten Details sinnvoll versteckt. Dabei greift es auf die Stärken von rsync zurück, überträgt nur tatsächlich geänderte Daten und lässt sich sowohl für die Sicherung mit wiederherstellbaren Schnappschüssen als auch zur Datensynchronisation einsetzen. Insgesamt eine benutzerfreundliche Alternative zu reinen rsync-Befehlen auf der Konsole.

Posted on

Backup leicht gemacht: Lokale und entfernte Sicherung mit Dirvish, Rsync und SSH

An mehreren Stellen habe ich hier schon meine ganz persönlichen Backup-Methoden vorgestellt.

  1. Keep it simple
  2. Partimage
  3. Partclone
  4. The Debian Way
  5. Apt-Clone
  6. Live-CDs (z.B. Clonezilla)

Die Reihe könnte man noch eine Weile mit weiteren guten Alternativen fortführen. Oft kombiniere ich auch die ein oder andere Variante, wenn mir Daten besonders wichtig sind. In den vergangenen Wochen habe ich mir endlich Dirvish näher angeschaut, das Rsync und SSH miteinander verbindet und mir wieder einmal die Frage gestellt: "Warum eigentlich nicht früher?". 🙂 Wer sowieso schon Rsync und SSH kennt, aber sich die vielen Kommandos nicht merken oder sogar Skripte dafür schreiben möchte, kann ganz einfach auf Dirvish zurückgreifen, das diese Probleme schon vor einer Dekade gelöst hat.
Interessant ist Dirvish nicht nur für alle, die gerne nach besonders effizienten Lösungen für die Konsole suchen, sondern es besticht vor allem durch die einfache Konfiguration und der Möglichkeit die Sicherung vollautomatisch per Cron-Job ablaufen zu lassen und kann auch ganz leicht manuell bedient werden.
Im Folgenden beschreibe ich die Sicherung eines Laptops und eines entfernten vServer mit Hilfe von Dirvish, Rsync und SSH. Dabei werden alle Daten auf eine handelsübliche USB-Festplatte gesichert, die an den Laptop angeschlossen ist.

Backup eines lokalen Rechners auf eine USB-Festplatte mit Dirvish

aptitude install dirvish

Nach der Installation von Dirvish, welches auch automatisch Rsync als Abhängigkeit mitinstalliert, könnt ihr mit der Dokumentation in /usr/share/doc/dirvish/HOWTO.Debian.gz und im dazugehörigen Beispiel-Ordner sofort loslegen. Für die gesamte Konfiguration sind lediglich zwei Dateien entscheidend.

master.conf

Die Datei master.conf wird nach /etc/dirvish/master.conf kopiert. Hierin werden alle globalen Einstellungen festgeschrieben.

  • bank: Gibt den Pfad zum Speicherort der Sicherung an. In meinem Fall existieren zwei Verzeichnisse auf einer externen USB-Festplatte, der ich zuvor mit
    tune2fs -L backup /dev/mapper/udisks-uuid-und-noch-mehr-Text
    einen kürzeren und leichter zu merkenden Namen gegeben habe. Wenn man schon dabei ist, kann man sie auch gleich mit luksformat vorher verschlüsseln.
  • exclude: Definiert die Verzeichnisse, die nicht gesichert werden sollen.
  • Runall: Die zuerst angegebenen Namen bezeichnen die sogenannen Schließfächer (vault), in denen die Daten gespeichert werden. Ein Schließfach ist nichts anderes als ein Unterverzeichnis, das man nach dem zu sichernden Dateisystem benennen sollte. Der Zeitstempel definiert nicht den Zeitpunkt der Ausführung, sondern dient lediglich als Bezugspunkt. Sollte das Backup z.B. aus welchen Gründen auch immer später ausgeführt werden, wird die Sicherung auf 22.00 Uhr zurückdatiert, damit die Logik intakt bleibt.
  • expire-default: Kann z.B. never oder +15 days sein und gibt an, wie lange einzelne Sicherungen standardmäßig vorgehalten werden sollen.
  • expire-rule: Wer den Aufbau der Datei crontab kennt, weiß sofort um was es geht. Die erste Zeile besagt, dass am ersten Tag der Woche, dem Montag, erstellte Backups für 3 Monate vorgehalten werden sollen. Man kann mit Hilfe dieser Syntax weitere beliebige Zeiträume und Zeitpunkte definieren.
bank:
	/media/backup/dirvish/laptop
	/media/backup/dirvish/server
exclude:
	lost+found/
	proc/
Runall:
	laptop-root	22:00
	laptop-home	22:00
	server-root	22:00
expire-default: +15 days
expire-rule:
#       MIN HR    DOM MON       DOW  STRFTIME_FMT
	*   *     *   *         1    +3 months
#	*   *     1-7 *         1    +1 year
#	*   *     1-7 1,4,7,10  1
#	*   10-20 *   *         *    +4 days
#	*   *     *   *         2-7  +15 days

Der Laptop

Erstellt nun die zweite Konfigurationsdatei für das Schließfach laptop-root. In diesem Beispiel wäre das
/media/backup/dirvish/laptop/laptop-root/dirvish/default.conf.
Default.conf ist immer richtig und für die meisten Anwendungsfälle vollkommen ausreichend. Es lassen sich aber noch zusätzliche Konfigurationen erstellen (Branch).

client: laptop
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak
        /proc/**

Die Datei ist ähnlich wie die Datei master.conf aufgebaut. Wichtig sind hierbei vor allem:
client: In diesem Fall laptop. Wenn dieser Name dem Rechnernamen entspricht (hostname), erkennt Dirvish automatisch, dass es sich um ein lokales Backup handelt und verwendet kein SSH.
tree: Welches Verzeichnis gesichert werden soll. In diesem Fall das gesamte Wurzelverzeichnis.
xdev: Kann den Wert 1 oder 0 annehmen. 1 bedeutet, dass die Sicherung auf das angegebene Dateisystem beschränkt bleibt und Dirvish z.B. eingehängten Verzeichnissen nicht folgen wird. Hat man wie ich /home auf eine andere Partition installiert, würde dieses beim Wert 1 nicht gesichert werden. Hierzu muss also ein weiteres Schließfach mit einer neuen default.conf angelegt werden oder man setzt xdev hier auf 0.
Des Weiteren lässt sich der Zeitstempel für das Backup festlegen und Verzeichnisse von der Sicherung ausschließen. Diese Regel gilt zusätzlich zu den in der master.conf getroffenen Einstellungen.
Für das Schließfach "latop-home" müsst ihr noch einmal die Schritte gehen. Hier ändert sich nur der Wert der tree-Variable auf /home und ggf. die ausgeschlossenen Verzeichnisse.

Die erste Sicherung - Initialisieren

dirvish --vault laptop-root --init
dirvish --vault laptop-home --init

Am nächsten Tag könnt ihr dann mit

dirvish-runall

ein neues Backup erstellen, bei dem nur die geänderten Daten gesichert werden. Aufgrund der Verwendung von Hardlinks und der inkrementellen Natur der Datensicherung wird deswegen nur wenig Speicherplatz benötigt. Wird dieser doch einmal knapp, lässt sich mit

dirvish-expire

Platz schaffen, indem die in der master.conf definierten Regeln Anwendung finden.
Wer einen eigenen Heimserver betreibt, kann auch die Einstellungen in /etc/cron.d/dirvish beibehalten, die dafür sorgen, dass Dirvish automatisch um 04.22 Uhr ausgeführt wird. Wer den Rechner nicht 24/7 laufen lässt, sollte die Datei entfernen oder den Cron-Job auskommentieren.

Entfernte Sicherung eines vServers mit Hilfe von SSH

Wenn ihr bis hierher gefolgt seid, dann ist die Datensicherung eures vServers, auf die an euren Laptop angeschlossene USB-Festplatte, ein Kinderspiel.
Ihr benötigt dafür auf jeden Fall das Paket SSH, einen Account auf dem Server und SSH-Schlüssel. Weiterhin gehe ich davon aus, dass ihr wie im alten Beitrag beschrieben den Port des SSH-Servers geändert habt und Root sich nicht anmelden darf.
Diese Beschränkung heben wir nun wieder auf, da wir den kompletten vServer sichern wollen. Aber...Root darf nur ein einzelnes Kommando über SSH ausführen, den Rsync-Befehl, und sonst nichts.

Default.conf des Servers auf dem Backup-Rechner

client: server
rsh: ssh -p 44444 -i '/root/.ssh/id_rsa'
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak

Der entscheidende Unterschied zu der lokalen Sicherung der Daten des Laptops ist der geänderte Wert für client: und die Variable rsh. Am besten tragt ihr in /etc/hosts einen Alias für eure Server-IP ein und nennt diesen dann schlicht server.
Der Wert für rsh (remote shell) ist der SSH-Befehl, um sich mit einem SSH-Server und dem SSH-Schlüssel zu verbinden, der auf einem Nicht-Standardport Anfragen entgegennimmt.

Auf dem Server

In der Datei /etc/ssh/sshd_config den Wert für PermitRootLogin auf forced-commands-only setzen.
Danach noch dem öffentlichen SSH-Schlüssel in /root/.ssh/authorized_keys eine Bedingung voranstellen, die erfüllt sein muss, damit sich Root anmelden darf. (vor ssh-rsa schreiben)

command="rsync --server --sender -vlHogDtprxe.iLsf --numeric-ids . /",from="10.0.0.5",no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Mit from= lässt sich sogar die IP-Adresse einschränken, von der sich Root anmelden darf. Der Befehl selbst lässt sich leicht mit htop auf dem Server herausfinden, wenn man ein Dirvish-Backup beobachtet oder man macht es wie Thor Dreier mit einem Hilfsskript, von dem auch dieser exzellente Dirvish-Tipp stammt. Sein Artikel aus dem Jahr 2005 ist auf jeden Fall empfehlenswert.

Fazit

Dirvish ist eine alte, aber noch lange nicht ergraute Lösung zum Sichern von Daten. Mit Hilfe auch gerne etwas älterer Hardware, habt ihr im Handumdrehen eine Backup-Lösung für alle Rechner zu Hause und für das Rechenzentrum in Schweden. 😉

Posted on

apt-clone: Backup in verbesserter Debian-Manier

Eher durch Zufall bin ich erneut auf apt-clone gestoßen, nachdem ich nach Programmen mit vorangestelltem "apt-" gesucht hatte. Vor einem Jahr wurde dieses schicke Skript auf linuxundich.de vorgestellt, als apt-clone noch dabei war in Debian aufgenommen zu werden.
Apt-clone ist im Prinzip der verbesserte "The Debian Way" beim Backup machen.
Es übernimmt automatisch das Sichern des Paketstatus, speichert den Schlüsselring und kann sogar nicht mehr herunterladbare Pakete oder Drittprogramme mit dpkg-repack wieder in neue Pakete verschnüren. Ziemlich praktisch, wenn man seine Druckertreiber gelöscht hat und diese nun neu gepackt werden.

Backup machen

apt-clone clone /home/apo --with-dpkg-repack

Wiederherstellen

apt-clone restore apt-clone-state-rechnername.tar.gz


Die Syntax ist ziemlich übersichtlich. Mit apt-clone clone wird ein Backup gemacht und in meinem Home-Verzeichnis gespeichert und zusätzlich nicht mehr verfügbare Pakete neu gepackt. Nach kurzer Zeit landet alles in einer Tar-Datei und kann mit apt-clone restore wiederhergestellt werden. Das wars.
Sicher ein Vorteil, wenn man den aktuellen Paketzustand des Rechners dauerhaft klonen möchte. Zusätzlich muss dennoch /etc und /home gesichert werden, was aber in den meisten Fällen ausreichend ist um ein Debian-basiertes System zu sichern und wieder ruhig schlafen zu können :).

Posted on

XZ-Kompression, Wheezy Freeze und ab Ubuntu 12.10 keine CDs mehr

Auf der Mailingliste der Debian-Entwickler, debian-devel, wurde vorgestern ein interessantes Thema in Gang gesetzt: "Wheezy release: CDs are not big enough any more"
Irgendwann hat es die Floppies erwischt, nun scheint es so, als ob CDs das gleiche Schicksal ereilen würde. Der Platz geht aus. Debian und Ubuntu unterstützen bisher die Installation einer kompletten Desktopumgebung mit Gnome, KDE, Xfce und LXDE mit jeweils einer separaten CD. Zusätzlich existieren noch Live-CDs, die ich schon scherzhaft in Kebian, Lebian und Xebian umbenennen wollte. Für die restlichen mehr als 30000 Pakete werden weitere CD-Abbilder vorgehalten, die in der Regel nicht gebraucht werden, sofern man über einen Internetanschluss verfügt.
Da der Freeze für Wheezy immer näher rückt, angepeilt ist die zweite Hälfte des Juni, hat Steve McIntyre auf debian-devel die Frage gestellt, wie man nun alle notwendigen Daten auf nur eine CD unterbringen will.

XZ-Kompression

Tatsache ist, dass auch schon in der Vergangenheit nicht jede Komponente des Gnome-Desktops auf der ersten CD Platz fand und deswegen die fehlende Software über das Internet nachgeladen werden mussten. Ein möglicher Lösungsansatz ist die Verwendung von XZ-Kompression anstatt von gzip oder bzip2, das Aufgeben von CDs zu Gunsten von DVDs oder gar die Abkehr von Gnome als Standardinstallation hin zu leichtgewichtigeren Desktopumgebungen wie z.B. LXDE.
XZ-Kompression, auch bekannt unter dem Namen des verwendeten Algorithmus LZMA, bietet hier einige Vorteile. Wer die xz-utils installiert hat und z.B. mit tar und der Option "-J" Daten komprimiert, stellt schon bald die deutlich verbesserte Kompressionsrate fest. XZ scheint bei mir Daten förmlich zu "verdampfen". Große Abbilder von Festplatten oder Partitionen, die ich mit Partimage oder Partclone sichere, werden regelmäßig mit xz komprimiert und auch die ein oder andere SQL-Datei schrumpfte schon von 109 MB auf lediglich 15 MB zusammen. Gerade für Backupzwecke und zum Platzsparen, wenn Daten Monate oder gar Jahre unangetastet bleiben, ist das äußerst nützlich.
Der Nachteil liegt jedoch in der speicher- und zeitintensiveren Erzeugung der Kompression gegenüber den etablierten Formaten gz und bz2. Im Gegensatz dazu erfolgt die Dekompression der Daten nur unwesentlich langsamer als bei gzip und ist ungefähr doppelt so schnell als bei bzip2. Das macht XZ gerade für das Komprimieren von Binärdateien und Softwarepaketen interessant. Arch Linux hat hier schon vor zwei Jahren umgestellt.
Da die Rechenleistung auf den Build-Daemons zur Erzeugung von Binärdateien anfallen, bekommt der Endanwender von der Veränderung nichts mit, sieht man mal von der geringeren Dateigröße ab. Im gleichen Entwickler-Thread wurde aber auch ein Problem eines universellen Betriebssystem angesprochen, denn Debian lässt sich auch mit Hilfe von Debootstrap von fremden Systemen aus installieren. Da ältere Versionen von Debootstrap XZ noch nicht unterstützen, könnte das auch auf Android-Smartphones mit Debian zum Problem werden.

Was macht Ubuntu?

Wie geht Ubuntu mit der selben Herausforderung um? Steve Langasek, Debian-Entwickler, ehemaliger Release Manager und jetzt Angestellter von Canonical, kündigte hier schon mal für Ubuntu 12.10 an, dass es keine CDs mehr geben und die Größe des Installationsabbildes auf 800 MB anwachsen wird. In Zukunft werden also nur noch DVDs, USB-Sticks und natürlich die Netzinstallation unterstützt.
In Anbetracht des bevorstehenden Freeze bei Debian kann ich mir vorstellen, dass die Umstellung auf XZ-Kompression bei den Binärpaketen noch etwas aufgeschoben wird, die das eigentliche Problem leider auch nur verlangsamen können. Für eher wahrscheinlich halte ich da das Szenario "Keine CDs mehr" oder "CD1 + CD2" für eine Desktopinstallation.
Für mich steht aber schon heute fest, ich bleibe weiterhin bei der Netzinstallation bzw. alternativen Installation von Ubuntu. Wie seht ihr das? Sind CDs Geschichte?

Posted on

Eine weitere simple Backup-Methode: Partclone, TinyCore und sshfs

Ein Backup zu machen ist das A und O. Ein Satz, den man regelmäßig liest und dem man auch zustimmen kann, nur um es dann doch auf die lange Bank zu schieben bis es schließlich zu spät ist. So etwas nennt man dann PP, Persönliches Pech. 😮
Die Auswahl für ein Backup reicht von Keep it simple, über "The Debian Way" bis hin zu einer kompletten Linuxdistribution, die Festplatten und Partitionen klonen und wiederherstellen kann.
Auf etwas älteren Laptops wie dem Thinkpad 600 funktioniert für mich auch die Partimage-Methode, indem ich von meinem Debian Stable aus eine weitere Partition sichere und bei Bedarf wieder einspiele.
Trotzdem ich freundlicherweise sogar Bilder zur Verfügung gestellt bekommen habe, wie man mit Hilfe von Clonezilla selbst mit nur 128 MB RAM ein vollständiges Festplattenbackup machen kann, hat dies bei mir leider noch nicht hingehauen.
Da es aber keine Rolle spielt, welche Linuxdistribution man benutzt, sondern nur, DASS es funktioniert, bin ich ziemlich glücklich, dass ich mit TinyCore nun die Möglichkeit habe ein vollständiges Backup durchzuführen.
Dazu muss man lediglich noch die Erweiterungen partclone.tcz und sshfs-fuse.tcz installieren. Partclone bietet gegenüber Partimage den Vorteil mehr Dateisysteme sichern zu können, darunter auch ext4 und btrfs.
Mit Hilfe von SSH lässt sich ein entferntes Dateisystem auf einem anderen Rechner einhängen und das Backup direkt an diesen Computer übertragen. Bei TinyCore muss man entweder die Rechte für den Standardnutzer tc konfigurieren oder mit sudo su als root die folgenden Kommandos ausführen.

Mit dem entfernten Rechner verbinden

mkdir /home/tc/backup
sshfs user@192.168.0.201:/home/user /home/tc/backup

Partition mit Partclone sichern

partclone.extfs -c -d -s /dev/sda2 -o /home/tc/backup/20111205_hal600_sda2.img

Partition mit Partclone wiederherstellen

partclone.restore -d -s /home/tc/backup/20111205_hal600_sda2.img -o /dev/sda2

MBR mit dd sichern

dd if=/dev/sda bs=512 count=1 of=/home/tc/backup/20111205_hal600_mbr.img



Mit den oben genannten Beispielen habe ich sowohl die zweite Partition der Thinkpad 600 Festplatte als auch den MBR und die Partitionstabelle gesichert und mit Hilfe des SSH-Dateisystems an einen entfernten Rechner übertragen. Je nach Interesse lassen sich mit TinyCore noch eine ganze Reihe anderer Möglichkeiten mit älterer Hardware verwirklichen.

Posted on

Nur gute Nachrichten

Heute ist mir eingefallen, dass es eine ganz einfache Möglichkeit gibt herauszufinden, ob ein Rechner Hardwareprobleme mit sich herumträgt oder einfach nur die Software verbugt ist. Man muss nur ein älteres Backup einspielen als alles noch problemlos funktionierte und die Ergebnisse mit der aktuellen Situation vergleichen. 🙄
Nachdem ich diesen Geistesblitz hatte, schnappte ich mir ein mehr als zwei Monate altes Partitionsabbild meines minimalen Debian-Spielesystems, holte Clonezilla wieder hervor, spielte das Image ein und siehe da, keine X-Server-Abstürze und auch keine wirren Nvidia-Treiber-Fehlermeldungen mehr.
Besser so herum als feststellen zu müssen, dass man sich eine neue Graka oder gar PC kaufen muss. Wie zu erwarten war steckt der Fehlerteufel irgendwo zwischen den neuesten Nvidia-Treibern und dem Xorg-Server. Nur um zu sehen wie effektiv das Ganze ist, habe ich nun alle Nvidia- und Xorg-Pakete mit aptitude auf "hold" gesetzt und bin gespannt wie sich das System in Zukunft verhalten wird.
Für ein Spielesystem halte ich zwar nach wie vor aktuelle Treiber für das A und O, doch diese gegen ein instabiles System einzutauschen macht keinen Sinn. Klammert man das Treiberproblem aus, funktioniert Debian Unstable auf der Maschine ausgezeichnet. Als Alternative bietet sich in Zukunft zum Vergleich an einmal Debian Stable zu installieren und die Treiber und den Xorg-Server aus den Backports oder sogar manuell zu installieren.

Debian Backup und Neuinstallation

Da ich gerade in Schwung war, habe ich mich entschieden das parallel installierte Hauptsystem auf Basis von Debian Testing (i386) gegen ein amd64 gleichen Typs auszutauschen. Als ich die Idee zu dem Multibootsystem hatte, wollte ich mit i386 auf Nummer sicher gehen, aber da der Core Duo 64bit unterstützt und ich Debian Testing darauf ausschließlich als Arbeits-PC benutze, macht es keinen Sinn an i386 festzuhalten.
Da ich nicht bis zur Marktreife von Multiarch warten wollte, wenn es möglich sein wird ein i386 System auf amd64 upzugraden, habe ich mich für die althergebrachte Neuinstallation und "The Debian Way" entschieden. Ich hatte das komplette Home- und Etc-Verzeichnis gesichert, auf die Paketliste von dpkg aber verzichtet.
Es genügte vollkommen das Verzeichnis /home nach der Neuinstallation wieder einzuspielen und eine Handvoll Konfigurationsdateien aus dem alten Verzeichnis /etc manuell in das neue zu verschieben. Metapakete wie gnome-core waren schnell installiert und auch der Rest war lediglich ein

aptitude install Paketname

Nun muss sich das RAM-Problem nur noch irgendwie von selbst lösen. 😉

Posted on

Partimage: Simple Backupmethode auch für ältere Rechner

Der neue Thinkpad 600 besitzt "nur" 128 MB RAM, womit die bequemste Backupmethode mit Clonezilla auf diesem Gerät für mich entfällt und ich eine Kernelpanic erhalte. Falls es doch jemand schon mit dieser begrenzten RAM-Zahl geschafft haben sollte, würde ich gerne wissen wie. 😉
Alles kein Problem, denn man kann natürlich auch direkt auf die Werkzeuge zugreifen, die Clonezilla unter einer ausgefeilten Oberfläche zum Einsatz bringt. Ich habe mich für Partimage entschieden, welches ich von der Debian-Squeeze-Installation aus benutze, um parallel installierte Distributionen zu sichern. Die Bedienung ist simpel. Zuerst wird die Partition für das Backup ausgewählt (in meinem Fall sda3) und dann in eine Image Datei geschrieben.
Der Zielpfad liegt bei meinem eingehängten USB-Stick in /media/data/. Mit F5 geht es danach zur nächsten Seite, wo man auswählen kann, ob man mit oder ohne Kompression sein Backup sichern möchte.



Viel mehr gibt es auch nicht zu sagen. Sowohl das Backup als auch die Rücksicherung funktionierten bisher immer einwandfrei. Je nach Größe des Abbilds dauert es auf dem alten Laptop mit USB 1.0 zwischen 5 und 20 Minuten ein Backup zu sichern.

Posted on

Linux-Backup the Debian way

Nachdem ich in den letzten beiden Beiträgen meine Backupmethode und ein paar Distributionen zum Klonen der gesamten Festplatte vorgestellt habe, hier eine typische Debian Methode um ein Problem zu lösen.
Wer nicht unbedingt auf eine externe Lösung zurückgreifen möchte, um sein System zu klonen, kann mit Hilfe von Debians Paketverwalter dpkg seine Paketliste mit der aktuell installierten Software in eine Textdatei ausgeben und sichern lassen. Bei einer Systemwiederherstellung muss diese wiederum mit dem Paketverwalter eingelesen werden, wonach nur noch ein

aptitude update
aptitude safe-upgrade

genügt, um die ursprüngliche Software erneut zu installieren und das Ausgangssystem wiederherzustellen.

Auf dem Quellrechner
dpkg --get-selections > meine_auswahl

Auf dem Zielrechner
dpkg --clear-selections
dpkg --set-selections < meine_auswahl

Es empfiehlt sich auch den Ordner /etc und /home zu sichern, damit eventuell geänderte Einstellungen auf das neue System übertragen werden können.

Der Vorteil bei der Debian Methode

  • Keine externe Anwendung oder Distribution notwendig
  • Sehr einfach und schnell auf dem Quellrechner zu sichern.
  • Es müssen nur die wichtigsten Konfigurationsdateien gesichert werden.

Der Nachteil

  • Viele Pakete müssen ggf. neu installiert werden, was Zeit bei der Wiederherstellung kostet.

Mehr dazu findet sich auch auf der man Seite von dpkg.

Posted on

Linuxdistributionen für Datenrettung und Backup

Glücklich dürfen sich diejenigen schätzen, die niemals einen Hardwaredefekt erlebt haben und plötzlich um ihre Daten bangen mussten. Bei mir ist das zum Glück auch schon Jahre her und auch nur auf einem Testrechner passiert, aber komplett ausschließen lässt es sich leider nie.
Für mich funktioniert bei Backups meine "Keep it simple"-Strategie, doch natürlich gibt es unter Linux auch die Möglichkeit seine gesamte Festplatte oder eine Partition zu klonen und als Image auf einen externen Datenträger zu sichern und noch weitere nützliche Werkzeuge.

Clonezilla


Clonezilla ist eine auf Debian oder Ubuntu basierende Linuxdistribution, deren Zweck es ist Festplattenabbilder zu erzeugen und wiederherzustellen. Darüber hinaus beherrscht Clonezilla die Fähigkeit die Images auf mehrere Rechner gleichzeitig per Multicasting zu übertragen. Für Normalnutzer sicher nicht so wichtig, für große Netzwerke aber sehr effizient und zeitsparend.
Es gibt zwei Versionen. Die auf Debian basierende ist vollständig Open Source inklusive aller im Linuxkernel enthaltenen Firmwaretreiber. Die Ubuntu-Version bietet dafür Unterstützung auch für nicht freie Firmware. 192 MB RAM sind die Mindestvoraussetzung.
Es werden alle wichtigen Dateisysteme für Linux, Windows, MacOS und BSD unterstützt und auch verschlüsselte Festplatten lassen sich mit dem universellen Backup Programm dd klonen.
Die Bedienung ist menügesteuert oder kann zwecks Automatisierung auch kommandozeilenorientiert erfolgen. Auf der offiziellen Seite finden sich Screenshots, die die einzelnen Menüs von Clonezilla zeigen.


Ein schönes Feature ist die Möglichkeit das Backup über SSH, Samba oder NFS zu übertragen. Die Geschwindigkeit beim Backup/Wiederherstellen empfinde ich als sehr hoch, dank Clonezillas Fähigkeit nur tatsächlich belegte Sektoren auszulesen.
Einziger Wermutstropfen ist die Tatsache, dass mit LUKS verschlüsselte Partitionen nur mit dd gesichert werden können, was viel Zeit in Anspruch nimmt.
Die Sprachunterstützung nimmt weiter zu, Deutsch ist aber noch nicht darunter. Wer sich nicht vor Englisch und ein paar Menüs scheut, findet hier eine hervorragende Open Source Lösung zum Sichern seiner Festplatten.

PartedMagic


PartedMagic ist eine Systemrettungs-CD, deren Schwerpunkt bei Partitionierung, Wiederherstellung und Sicherung von Daten liegt. Um vollständig im RAM zu laufen, werden mindestens 312 MB RAM vorausgesetzt. Der Live Modus mit CD lässt sich aber auch schon mit weniger als 175 MB RAM direkt in eine LXDE Desktopumgebung starten.
Läuft PartedMagic im Hauptspeicher ist die Reaktionszeit aller Programme naturgemäß hervorragend. Dabei bietet PM eine Plethora an Freier Software, die Systeminformationen und Sensordaten ausliest, Daten versucht wiederherzustellen oder dauerhaft zu löschen, die Festplatte zu partitionieren und mit Hilfe des integrierten und weiter oben vorgestellten Clonezilla auch die Möglichkeit hat ganze Festplatten zu klonen.
Des weiteren existiert noch Truecrypt, ein Programm zum Verschlüsseln von Ordnern und Festplatten, welches zwar Freie Software ist, auf Grund der besonderen Lizenz aber nicht bei Debian und Ubuntu integriert ist.
Ebenfalls interessant: Im Bootmenü der Live CD findet sich unter Extras auch SuperGrubDisk oder PlopBootManager.


Dabei bietet PartedMagic noch eine komplette grafische Desktopumgebung mit Browser, Dateimanager, Musikprogramm, Bildbetrachter, Konfigurationswerkzeuge, eine deutsche Sprachumgebung und noch viel mehr.

SystemRescueCD


Ebenfalls als Rettungs-CD konzipiert basiert SystemRescueCD auf Gentoo Linux. Diese stellt ebenso wie PartedMagic eine Reihe von Systemwerkzeugen zur Verfügung um seine Daten bei einem eventuell Schaden zu sichern, die Festplatte neu zu partitionieren oder mittels clamav nach Viren zu durchsuchen.
Eine Übersicht über alle Programme gibt es hier.
Hervorzuheben ist, dass die Dokumentation von SystemRescueCD in Deutsch ist. Gegenüber der PartedMagic CD fehlen aber Clonezilla, SuperGrubDisk oder PlopBootManager, auf die ich für eine Rettungs-CD nicht verzichten mag.


Optisch gefällt mir PartedMagic besser als die SystemRescueCD, aber das soll nicht wirklich ein ausschlaggebendes Kriterium für eine Rettungs-CD sein.

Fazit

Clonezilla ist eine hervorragende Anwendung, wenn es um das Klonen der eigenen Daten geht. Wer gerne sein Linux komplett sichert, auf externen Festplatten abspeichert und jederzeit genauso einfach wiederherstellen möchte, greift zu Clonezilla.

Soll es mehr sein und benötigt man weitere Linuxwerkzeuge zum Modifizieren, Löschen, Wiederherstellen seiner Daten, empfehle ich PartedMagic, das idealerweise schon Clonezilla integriert hat.
Ich konnte die SystemRescueCD zu wenig Testen um ein Urteil fällen zu können. Auf den ersten Blick habe ich keinen Grund gesehen, warum man nicht auch PartedMagic nehmen könnte, vor allem weil hier schon Clonezilla integriert wurde.
Nicht zu vergessen, es gibt natürlich auch noch Grml, dass sich ebenfalls dem Ziel der Datensicherung verschrieben hat.