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.

luckyBackup: Die benutzerfreundliche Datensicherung mit rsync

Was Backup-Lösungen angeht halte ich es am liebsten einfachRsync 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.

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. 😉

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 :).

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?