Kapitel 10. Datenmanagement

Inhaltsverzeichnis

10.1. Austauschen, kopieren und archivieren von Dateien
10.1.1. Archivierungs- und Kompressionswerkzeuge;
10.1.2. Kopier- und Synchronisationswerkzeuge;
10.1.3. Aufrufe für Archivierungsoperationen
10.1.4. Aufrufe für Kopieroperationen
10.1.5. Aufrufe für die Auswahl von Dateien
10.1.6. Archivierungsmedien
10.1.7. Wechseldatenträger
10.1.8. Dateisystemauswahl für den Datenaustausch
10.1.9. Datenaustausch über das Netzwerk
10.2. Datensicherung und -wiederherstellung
10.2.1. Programmsammlungen für Datensicherungsaufgaben
10.2.2. Ein Beispielskript für die Systemsicherung
10.2.3. Ein Kopierskript für die Datensicherung
10.3. Daten-Sicherheitsinfrastruktur
10.3.1. Schlüsselverwaltung für GnuPG
10.3.2. Verwendung von GnuPG mit Dateien
10.3.3. Verwendung von GnuPG mit Mutt
10.3.4. Verwendung von GnuPG mit Vim
10.3.5. Die MD5-Prüfsumme
10.4. Werkzeuge zur Quellcode-Zusammenführung
10.4.1. Unterschiede für Quelldateien extrahieren
10.4.2. Aktualisierungen für Quelldateien zusammenführen
10.4.3. Aktualisierung via 3-Wege-Zusammenführung
10.5. Versionskontrollsysteme
10.5.1. Gegenüberstellung von VCS-Befehlen
10.6. Git
10.6.1. Konfiguration eines Git-Clients
10.6.2. Weitere Referenzen zu Git
10.6.3. Git-Befehle
10.6.4. Git mit einem Subversion-Depot
10.6.5. Git zur Aufzeichnung der Historie von Konfigurationsdateien
10.7. CVS
10.7.1. Konfiguration eines CVS-Depots
10.7.2. Lokaler Zugriff auf CVS
10.7.3. Fernzugriff auf CVS mit pserver
10.7.4. Fernzugriff auf CVS mit ssh
10.7.5. Eine neue Quelle in CVS importieren
10.7.6. Dateiberechtigungen im CVS-Depot
10.7.7. Arbeitsablauf bei CVS
10.7.8. Aktuellste Dateien von CVS
10.7.9. Administrierung von CVS
10.7.10. Ausführungs-Bit für CVS-Checkout
10.8. Subversion
10.8.1. Konfiguration eines Subversion-Depots
10.8.2. Zugriff auf Subversion über einen Apache2-Server
10.8.3. Lokaler Zugriff auf Subversion durch die Gruppe
10.8.4. Fernzugriff auf Subversion über SSH
10.8.5. Subversion-Verzeichnisstruktur
10.8.6. Eine neue Quelle in Subversion importieren
10.8.7. Arbeitsablauf bei Subversion

Hier werden Werkzeuge und Tipps zur Verwaltung von Binär- und Textdateien auf einem Debian-System beschrieben.

[Warnung] Warnung

Ein unkoordinierter Schreibzugriff auf Geräte und Dateien im aktiven Zugriff durch mehrere Prozesse ist nicht erlaubt, um eine Wettlaufsituation (Race Condition) zu vermeiden. Ein File locking-Mechanismus mittels flock(1) kann verwendet werden, um dies zu umgehen.

Die Sicherheit der Daten und das kontrollierte Austauschen derselben mit anderen hat verschiedene Aspekte:

  • Erzeugung von Datenarchiven;

  • Fern-Speicherzugriff;

  • Vervielfältigung;

  • Nachverfolgung der Änderungshistorie;

  • Erleichterung des Tauschens von Daten;

  • Verhinderung von unerlaubten Dateizugriffen;

  • Erkennung von unerlaubten Dateiveränderungen.

Diese können über die Verwendung einer Kombination von Werkzeugen realisiert werden:

  • Archivierungs- und Kompressionswerkzeuge;

  • Kopier- und Synchronisationswerkzeuge;

  • Netzwerk-Dateisysteme;

  • Wechseldatenträger;

  • Secure Shell;

  • Authentifizierungssysteme;

  • Versionskontrollsysteme;

  • Hash- und kryptographische Verschlüsselungswerkzeuge.

Hier eine Zusammenfassung von Archivierungs- und Kompressionswerkzeugen im Debian-System:

Tabelle 10.1. Liste von Archivierungs- und Kompressionswerkzeugen

Paket Popcon Größe Erweiterung Befehl Erläuterung
tar V:565, I:999 2614 .tar tar(1) der Standard-Archivierer (De-Facto-Standard)
cpio V:333, I:999 844 .cpio cpio(1) Unix-Archivierer im System-V-Stil, zu verwenden mit find(1)
binutils V:300, I:761 19469 .ar ar(1) Archivierer zur Erstellung von statischen Bibliotheken
fastjar V:8, I:82 191 .jar fastjar(1) Archivierer für Java (zip-artig)
pax V:19, I:71 147 .pax pax(1) neuer POSIX-Standard-Archivierer, Kompromiss zwischen tar und cpio
gzip V:862, I:999 239 .gz gzip(1), zcat(1), … GNU LZ77-Kompressionswerkzeug (De-Facto-Standard)
bzip2 V:405, I:904 119 .bz2 bzip2(1), bzcat(1), … Burrows-Wheeler Block-Sorting Kompressions-Werkzeug mit höherem Kompressionsverhältnis als bei gzip(1) (langsamer als gzip mit ähnlicher Syntax)
lzma V:10, I:127 144 .lzma lzma(1) LZMA-Kompressionswerkzeug mit höherem Kompressionsverhältnis als bei gzip(1) (überholt)
xz-utils V:212, I:946 472 .xz xz(1), xzdec(1), … XZ-Kompressionswerkzeug mit höherem Kompressionsverhältnis als bei bzip2(1) (langsamer als gzip, aber schneller als bzip2; ersetzt das LZMA-Kompressionswerkzeug)
p7zip V:9, I:91 966 .7z 7zr(1), p7zip(1) 7-Zip-Dateiarchivierer mit hohem Kompressionsverhältnis (LZMA-Kompression)
p7zip-full V:220, I:516 3810 .7z 7z(1), 7za(1) 7-Zip-Dateiarchivierer mit hohem Kompressionsverhältnis (LZMA- und andere Kompressionsalgorithmen)
lzop V:4, I:41 112 .lzo lzop(1) LZO-Kompressionswerkzeug mit höherer Kompressions- und Dekompressionsgeschwindigkeit als bei gzip(1) (niedrigeres Kompressionsverhältnis als gzip mit ähnlicher Syntax)
zip V:51, I:355 593 .zip zip(1) InfoZIP: DOS-Archivierungs- und Kompressionswerkzeug
unzip V:287, I:789 377 .zip unzip(1) InfoZIP: DOS-Dearchivierungs- und Dekompressionswerkzeug

[Warnung] Warnung

Setzen Sie nicht die "$TAPE"-Variable, außer Sie wissen, was Sie zu erwarten haben. Sie verändern dadurch das Verhalten von tar(1).

[Anmerkung] Anmerkung

Ein gezipptes tar(1)-Archiv verwendet die Dateierweiterung ".tgz" oder ".tar.gz".

[Anmerkung] Anmerkung

Ein xz-komprimiertes tar(1)-Archiv verwendet die Dateierweiterung ".txz" oder ".tar.xz".

[Anmerkung] Anmerkung

Populäre Kompressionsmethoden in FOSS-Programmen wie tar(1) haben sich mit der Zeit wie folgt verschoben: gzipbzip2xz.

[Anmerkung] Anmerkung

cp(1), scp(1) und tar(1) könnten einige Einschränkungen bei speziellen Dateien haben. cpio(1) ist dabei erheblich vielseitiger.

[Anmerkung] Anmerkung

cpio(1) wurde entwickelt, um zusammen mit find(1) und anderen Befehlen verwendet zu werden und ist geeignet, Backup-Skripte zu erstellen, da der Teil des Skriptes zur Dateiauswahl eigenständig getestet werden kann.

[Anmerkung] Anmerkung

Die interne Struktur von Libreoffice-Dateien entspricht der von ".jar"-Dateien.

Hier eine Zusammenfassung von einfachen Kopier- und Backup-Werkzeugen im Debian-System:


Das Kopieren von Dateien mit rsync(8) bietet bietet mehr Funktionalitäten als mit anderen Werkzeugen:

  • Delta-Transfer-Algorithmus, der nur die Unterschiede zwischen Quelle und den auf dem Ziel vorhandenen Dateien überträgt;

  • schneller Prüf-Algorithmus, der (standardmäßig) nach Dateien sucht, die sich in Größe oder Änderungs-Zeitstempel verändert haben;

  • die Optionen "--exclude" und "--exclude-from", vergleichbar mit denen von tar(1);

  • die Syntax des Schrägstrichs hinter dem Quellverzeichnis, die verhindert, dass eine zusätzliche Verzeichnisebene auf dem Zielort erstellt wird.

[Tipp] Tipp

Die Ausführung des (in Abschnitt 10.2.3, „Ein Kopierskript für die Datensicherung“ erwähnten) Skripts mit der Option "-gl" unter cron(8) sollte eine ähnliche Funktionalität bieten wie Plan9s dumpfs für statische Datenarchive.

[Tipp] Tipp

Versionskontrollsysteme (VCS) wie die in Tabelle 10.11, „Liste von Werkzeugen für die Versionskontrolle“ können ebenfalls als Mehrwege-Kopier- und Synchronisationswerkzeuge dienen.

Hier finden Sie mehrere Wege, um den kompletten Inhalt des Verzeichnisses "./source" mit verschiedenen Werkzeugen zu kopieren.

  • Lokale Kopie: "./source"-Verzeichnis → "/dest"-Verzeichnis

  • Kopie auf einen fernen Rechner: "./source"-Verzeichnis auf dem lokalen Rechner → "/dest"-Verzeichnis auf dem Rechner "user@host.dom"

rsync(8):

# cd ./source; rsync -aHAXSv . /dest
# cd ./source; rsync -aHAXSv . user@host.dom:/dest

Sie können alternativ auch die Syntax des Schrägstrichs am Ende des Zielverzeichnisses nutzen:

# rsync -aHAXSv ./source/ /dest
# rsync -aHAXSv ./source/ user@host.dom:/dest

Alternativ auch:

# cd ./source; find . -print0 | rsync -aHAXSv0 --files-from=- . /dest
# cd ./source; find . -print0 | rsync -aHAXSv0 --files-from=- . user@host.dom:/dest

GNU cp(1) und openSSH scp(1):

# cd ./source; cp -a . /dest
# cd ./source; scp -pr . user@host.dom:/dest

GNU tar(1):

# (cd ./source && tar cf - . ) | (cd /dest && tar xvfp - )
# (cd ./source && tar cf - . ) | ssh user@host.dom '(cd /dest && tar xvfp - )'

cpio(1):

# cd ./source; find . -print0 | cpio -pvdm --null --sparse /dest

Sie können in allen Beispielen, die einen "." enthalten, diesen "." durch "foo" ersetzen, um Dateien aus dem Verzeichnis "./source/foo" in das Verzeichnis "/dest/foo" zu kopieren.

Sie können auch in allen Beispielen, die einen "." enthalten, diesen "." durch einen absoluten Pfad wie "/pfad/zu/source/foo" ersetzen und auf "cd ./source;" verzichten. Dadurch werden, abhängig von den verwendeten Werkzeugen, die Dateien an unterschiedliche Orte kopiert:

  • nach "/dest/foo": rsync(8), GNU cp(1) und scp(1);

  • nach "/dest/pfad/zu/source/foo": GNU tar(1) und cpio(1).

[Tipp] Tipp

rsync(8) und GNU cp(1) haben die Option "-u", um Dateien zu überspringen, die am Zielort neuer sind als im Quellverzeichnis.

find(1) wird verwendet, um Dateien für Archivierungs- und Kopierbefehle auszuwählen (lesen Sie Abschnitt 10.1.3, „Aufrufe für Archivierungsoperationen“ und Abschnitt 10.1.4, „Aufrufe für Kopieroperationen“) oder für xargs(1) (Näheres in Abschnitt 9.3.9, „Einen Befehl wiederholt mit einer Schleife über verschiedene Dateien ausführen“). Dies kann mit deren Befehlsargumenten noch erweitert werden.

Die grundsätzliche Syntax von find(1) kann wie folgt zusammengefasst werden:

  • Seine bedingten Argumente werden von links nach rechts ausgewertet.

  • Diese Auswertung wird beendet, sobald ihr Resultat ermittelt wurde.

  • Ein "logisches ODER" (definiert über "-o" zwischen den Bedingungen) hat eine niedrigere Priorität als ein "logisches UND" (das über "-a" oder nichts zwischen den Bedingungen definiert wird).

  • Ein "logisches NICHT" (definiert über "!" vor der Bedingung) hat eine höhere Priorität als ein "logisches UND".

  • "-prune" liefert immer ein logisches WAHR zurück und, falls es ein Verzeichnis ist, wird die Suche nach Dateien an diesem Punkt beendet.

  • "-name" findet Dateien über den Anfang des Dateinamens mittels Shell-Glob-Suchmuster (lesen Sie dazu Abschnitt 1.5.6, „Shell-Glob“), findet sie aber über Metazeichen wie "*" und "?" auch bei einem führenden "." (neue POSIX-Funktionalität).

  • "-regex" findet Dateien mit vollständigem Pfad standardmäßig über Emacs-artige reguläre Ausdrücke (BRE, nähere Infos finden Sie in Abschnitt 1.6.2, „Reguläre Ausdrücke“).

  • "-size" findet Dateien basierend auf der Dateigröße (mit einem "+" vor dem Wert für größer, mit einem "-" für kleiner).

  • "-newer" findet Dateien, die neuer sind als die in dem Argument angegebene.

  • "-print0" liefert immer ein logisches WAHR zurück und gibt den kompletten Dateinamen (abgeschlossen durch ein Nullzeichen) auf der Standardausgabe aus.

find(1) wird oft in einem idiomatischen Stil verwendet, wie hier:

# find /pfad/zu \
    -xdev -regextype posix-extended \
    -type f -regex ".*\.cpio|.*~" -prune -o \
    -type d -regex ".*/\.git" -prune -o \
    -type f -size +99M -prune -o \
    -type f -newer /pfad/zu/zeitstempel -print0

Das bedeutet folgendes:

  1. nach allen Dateien suchen, beginnend in "/pfad/zu";

  2. die Suche global auf das Dateisystem beschränken, in dem sie begonnen hat, und stattdessen reguläre Ausdrücke (ERE, lesen Sie dazu Abschnitt 1.6.2, „Reguläre Ausdrücke“) verwenden;

  3. Dateien ausschließen, auf die die regulären Ausdrücke ".*\.cpio" oder ".*~" zutreffen, indem die Suche abgebrochen wird;

  4. Verzeichnisse ausschließen, auf die der reguläre Ausdruck ".*/\.git" zutrifft, indem die Suche abgebrochen wird;

  5. Dateien ausschließen, die größer als 99 Megabyte (1048576 Byte) sind, indem die Suche abgebrochen wird;

  6. Dateinamen ausgeben, die obige Suchkriterien erfüllen und neuer als "/path/to/timestamp" sind.

Bitte beachten Sie die idiomatische Verwendung von "-prune -o", um in obigen Beispielen Dateien auszuschließen.

[Anmerkung] Anmerkung

Auf Unix-artigen Nicht-Debian-Systemen könnten einige Optionen von find(1) nicht unterstützt sein. Versuchen Sie in diesem Fall, die Suchmethoden anzupassen und "-print0" durch "-print" zu ersetzen. Unter Umständen müssen Sie auch zugehörige Befehle anpassen.

Wenn Sie Speichermedien für Datensicherungen wichtiger Daten suchen, sollten Sie sorgfältig deren Einschränkungen abwägen. Für eine kleine persönliche Datensicherung verwende ich CD-R und DVD-R von einem Markenhersteller und lagere die Disks in einer kühlen, dunklen, trockenen und sauberen Umgebung. (Für die professionelle Nutzung scheinen Tapes (Speicherbänder) für die Archivierung sehr beliebt zu sein.)

[Anmerkung] Anmerkung

Ein feuerbeständiger Tresor ist gedacht für Dokumente in Papierform. Jedoch haben die meisten Speichermedien eine niedrigere Temperaturtoleranz als Papier. Ich baue auf mehrere sicher verschlüsselte Kopien, die an verschiedenen sicheren Orten aufgewahrt werden.

Optimistische Angabe der Lebensdauer von Speichermedien, gefunden im Internet (überwiegend Herstellerangaben):

  • 100 Jahre und mehr: säurefreies Papier mit Tinte

  • 100 Jahre: Optische Speichermedien (CD/DVD, CD-R/DVD-R)

  • 30 Jahre: Magnetische Speichermedien (Bänder, Disketten)

  • 20 Jahre: Optische Medien basierend auf Phasenänderung (CD-RW)

Hierbei sind keine mechanischen Ausfälle durch Handhabung usw. berücksichtigt.

Optimistische Angabe von Schreibzyklen der Speichermedien, gefunden im Internet (überwiegend Herstellerangaben):

  • 250000 Zyklen und mehr: Festplattenlaufwerk

  • 10000 Zyklen und mehr: Flash-Speicher

  • 1000 Zyklen: CD-RW/DVD-RW

  • 1 Zyklus: CD-R/DVD-R, Papier

[Achtung] Achtung

Die obigen Angaben zu Lebensdauer und Schreibzyklen sollten nicht bei Entscheidungen bezüglich kritischer Datenspeicherung verwendet werden. Bitte konsultieren Sie in diesem Fall die spezifische Produktinformation des Herstellers.

[Tipp] Tipp

Da CD-R/DVD-R und Papier nur einmal beschrieben werden können, schützen sie von Natur aus schon vor dem versehentlichen Datenverlust durch Überschreiben. Dies ist ein Vorteil!

[Tipp] Tipp

Wenn Sie eine schnelle und wiederholte Sicherung großer Datenmengen benötigen, könnte eine Festplatte in einem fernen Rechner, verbunden über eine schnelle Internetverbindung, die einzige realistische Option sein.

Wechseldatenträger können folgende Geräte sein:

Sie können über eine dieser Möglichkeiten verbunden sein:

Moderne Arbeitsplatzumgebungen wie GNOME und KDE können diese Wechseldatenträger auch ohne einen entsprechenden "/etc/fstab"-Eintrag automatisiert einbinden.

  • Das udisks-Paket enthält einen Daemon und dazugehörige Hilfsprogramme, um diese Datenträger automatisch einzubinden und zu trennen.

  • D-bus erzeugt Ereignisse, um automatische Prozesse anzustoßen.

  • PolicyKit stellt die erforderlichen Berechtigungen bereit.

[Tipp] Tipp

Automatisch eingebundene Geräte haben eventuell die mount-Option "uhelper=", die von umount(8) genutzt wird.

[Tipp] Tipp

In modernen Arbeitsplatzumgebungen funktioniert das automatische Einbinden von Laufwerken nur, wenn diese Geräte nicht in "/etc/fstab" aufgelistet sind.

Der Einbindungspunkt wird in modernen Umgebungen als "/media/<laufwerksbezeichnung>" gebildet und kann wie folgt angepasst werden:

  • mlabel(1) bei FAT-Dateisystemen;

  • genisoimage(1) mit der Option "-V" bei ISO9660-Dateisystemen;

  • tune2fs(1) mit der Option "-L" bei ext2-/ext3-/ext4-Dateisystemen.

[Tipp] Tipp

Die Auswahl der Zeichenkodierung muss unter Umständen als mount-Option angegeben werden (lesen Sie dazu Abschnitt 8.3.6, „Dateinamenkodierung“).

[Tipp] Tipp

Die Verwendung des grafischen GUI-Menüs zur Trennung eines eingebundenen Dateisystems könnte auch dessen dynamisch erzeugte Gerätedatei (z.B. "/dev/sdc" entfernen. Falls Sie diese Gerätedatei erhalten möchten, trennen Sie die Einbindung mit dem umount(8)-Befehl von einem Shell-Prompt.

Um Daten mit anderen Systemen über Wechseldatenträger auszutauschen, sollten Sie diese mit einem Dateisystem formatieren, das von beiden Systemen unterstützt wird.


[Tipp] Tipp

Details zum plattformübergreifenden Datenaustausch mit Verschlüsselung auf Geräteebene finden Sie in Abschnitt 9.8.1, „Verschlüsselung von Wechseldatenträgern mit dm-crypt/LUKS“.

Das FAT-Dateisystem wird von nahezu allen modernen Dateisystemen unterstützt und ist für den Datenaustausch über Wechseldatenträger sehr nützlich.

Wenn Sie Geräte wie externe Festplatten für den plattformübergreifenden Datenaustausch mit dem FAT-Dateisystem formatieren, sollten die folgenden Varianten eine sichere Wahl sein:

Wenn das FAT- oder ISO9660-Dateisystem für den Dateiaustausch verwendet wird, sollte folgendes eine sichere Variante sein:

  • archivieren der Dateien in eine Archivdatei mittels tar(1) oder cpio(1), um die langen Dateinamen, symbolischen Links, originalen Unix-Dateiberechtigungen und Benutzerinformationen zu erhalten;

  • splitten der Archivdatei in Stücke kleiner als 2 GiB mittels split(1), um so die Beschränkung der Dateigröße zu umgehen;

  • verschlüsseln der Archivdatei, um den Inhalt vor unberechtigtem Zugriff zu schützen.

[Anmerkung] Anmerkung

Bei dem FAT-Dateisystem liegt, begründet durch sein Design, die maximale Dateigröße bei (2^32 - 1) Byte = (4 GiB - 1 Byte). Bei einigen Anwendungen auf älteren 32-Bit-Betriebssystemen war die maximale Dateigröße sogar noch kleiner: (2^31 - 1) Byte = (2 GiB - 1 Byte). Debian ist von letzterem nicht betroffen.

[Anmerkung] Anmerkung

Microsoft selbst empfiehlt FAT nicht für Laufwerke oder Partitionen über 200 MB Größe. Microsoft hebt die Nachteile wie ineffiziente Speicherplatznutzung in seiner "Übersicht über die Dateisysteme FAT, HPFS und NTFS" hervor. Natürlich sollten wir für Linux normalerweise das ext4-Dateisystem nutzen.

[Tipp] Tipp

Mehr Informationen über Dateisysteme und Dateisystemzugriffe finden Sie im "Filesystems HOWTO".

Wir alle wissen, dass Computer manchmal defekt sein können oder menschliche Fehler System- und Datenausfälle verursachen. Aktionen zur Datensicherung und -wiederherstellung sind unverzichtbarer Teil einer erfolgreichen Systemadministration. Alle möglichen Fehlervarianten werden Sie eines Tages ereilen.

[Tipp] Tipp

Halten Sie Ihr Datensicherungssystem einfach und führen Sie häufig Sicherungen durch. Aktuelle Sicherungen von seinen Daten zu haben ist wichtiger als die technische Qualität der Sicherungsmethodik.

Es gibt drei Schlüsselfaktoren, die letztendig die Sicherungs- und Wiederherstellungsstrategie bestimmen:

  1. Zu wissen, was man sichern und wiederherstellen muss:

    • Daten, die direkt von Ihnen selbst erstellt wurden: Daten in "~/";

    • Daten, die von Anwendungen, die Sie verwenden, erstellt wurden: Daten in "/var/" (außer "/var/cache/", "/var/run/" und "/var/tmp/");

    • Systemkonfigurationsdateien: Daten in "/etc/";

    • Lokale Software: Daten in "/usr/local/" oder "/opt/";

    • Informationen zur Systeminstallation: Aufzeichnungen in reinem Textformat über wichtige Schritte (Partitionierung, …);

    • Daten, von denen Sie wissen, dass sie wichtig sind, bestätigt durch im Vornherein versuchsweise durchgeführte Wiederherstellungsoperationen.

  2. Wissen, wie Sie Daten sichern und wiederherstellen:

    • Sicheres Speichern von Daten: geschützt vor Überschreiben und Systemausfällen;

    • Häufige Datensicherungen: Sicherungen planen;

    • Redundante Datensicherungen: Spiegeln der Sicherungsdateien;

    • Idiotensicheres Vorgehen: Sicherung durch einen einfachen Befehl.

  3. Bewertung der entstehenden Risiken und Kosten:

    • Wert der Daten, falls Sie verloren gehen;

    • Für die Sicherung benötigte Ressourcen: Personen, Hardware, Software, …;

    • Mögliche Ausfälle und deren Wahrscheinlichkeit.

[Anmerkung] Anmerkung

Machen Sie keine Sicherungen von den Pseudo-Dateisystemen in /proc, /sys, /tmp und /run (Näheres dazu in Abschnitt 1.2.12, „procfs und sysfs“ und Abschnitt 1.2.13, „tmpfs“). Außer falls Sie genau wissen, was Sie tun, sind dies absolut nutzlose Daten.

Aus Gründen der sicheren Speicherung sollten die Daten zumindest auf verschiedenen Festplattenpartitionen, bevorzugt sogar auf separaten Festplatten und Rechnern abgelegt werden, um Beschädigungen von Dateisystemen standzuhalten. Wichtige Daten werden am besten auf Medien gespeichert, die nur einmal beschrieben werden können (wie CD-R/DVD-R), um versehentliches Überschreiben auszuschließen. (In Abschnitt 9.7, „Die Binärdaten“ lesen Sie, wie Sie von der Befehlszeile aus auf die Speichermedien schreiben können. Die grafische Oberfläche der GNOME-Arbeitsplatzumgebung bietet Ihnen auch einen einfachen Weg über das Menü: "Orte→CD/DVD-Ersteller".)

[Anmerkung] Anmerkung

Sie sollten eventuell einige Anwendungs-Daemons wie den MTA (lesen Sie dazu Abschnitt 6.3, „Mail Transfer Agent (MTA)“) beenden, während Sie die Datensicherung durchführen.

[Anmerkung] Anmerkung

Besondere Sorgfalt bei Sicherung und Wiederherstellung sollte Identitäts-bezogenen Dateien gelten, wie "/etc/ssh/ssh_host_dsa_key", "/etc/ssh/ssh_host_rsa_key", "~/.gnupg/*", "~/.ssh/*", "/etc/passwd", "/etc/shadow", "/etc/fetchmailrc", "popularity-contest.conf", "/etc/ppp/pap-secrets" und "/etc/exim4/passwd.client". Einige dieser Daten können nicht wiederhergestellt werden, selbst wenn die gleichen Eingaben erneut getätigt werden.

[Anmerkung] Anmerkung

Wenn Sie einen Cron-Job als Benutzerprozess ausführen, müssen Sie die Dateien im Verzeichnis "/var/spool/cron/crontabs" wiederherstellen und cron(8) neu starten. Informationen über cron(8) und crontab(1) finden Sie in Abschnitt 9.3.14, „Regelmäßige Aufgaben planen“.

Hier eine Auswahl erwähnenswerter, im Debian-System verfügbarer Datensicherungsprogramme:

Tabelle 10.5. Liste von Datensicherungsprogrammen

Paket Popcon Größe Beschreibung
dump V:1, I:9 592 4.4bsd dump(8)- und restore(8)-Programm für ext2/ext3/ext4-Dateisysteme
xfsdump V:1, I:14 789 dump (Abbilderstellung) und restore (Wiederherstellung) mit xfsdump(8) und xfsrestore(8) für das XFS-Dateisystem unter GNU/Linux und IRIX
backupninja V:4, I:4 277 ressourcenschonendes, erweiterbares Meta-Backup-System
sbackup V:0, I:0 488 einfache Datensicherungssuite für den GNOME-Arbeitsplatz
bacula-common V:10, I:20 1176 Bacula: Datensicherung, -wiederherstellung und -verifizierung über das Netzwerk - gemeinsame Hilfsdateien
bacula-client I:6 114 Bacula: Datensicherung, -wiederherstellung und -verifizierung über das Netzwerk - Client-Metapaket
bacula-console V:2, I:8 197 Bacula: Datensicherung, -wiederherstellung und -verifizierung über das Netzwerk - Textkonsole
bacula-server I:2 114 Bacula: Datensicherung, -wiederherstellung und -verifizierung über das Netzwerk - Server-Metapaket
amanda-common V:2, I:4 7000 Amanda: Advanced Maryland Automatic Network Disk Archiver (Netzwerk-Backup-System - Bibliotheken)
amanda-client V:2, I:4 773 Amanda: Advanced Maryland Automatic Network Disk Archiver (Netzwerk-Backup-System - Client)
amanda-server V:0, I:1 840 Amanda: Advanced Maryland Automatic Network Disk Archiver (Netzwerk-Backup-System - Server)
backuppc V:5, I:6 2045 BackupPC ist ein hochleistungsfähiges System der Enterprise-Klasse zur Datensicherung von PCs (festplatten-basiert)
backup-manager V:2, I:3 615 befehlszeilen-basiertes Datensicherungs-Werkzeug
backup2l V:1, I:1 78 wartungsarmes Sicherungs-/Wiederherstellungsprogramm für mount-fähige Medien (festplatten-basiert)

Datensicherungs-Werkzeuge haben alle ihren speziellen Fokus:

  • Mondo Rescue ist ein Backup-System, das die schnelle Wiederherstellung eines vollständigen Systems von CD/DVD ermöglicht, ohne dass dabei die normalen Systeminstallations-Prozesse durchlaufen werden müssen.

  • Die sbackup- und keep-Pakete enthalten eine einfache grafische GUI-Oberfläche für Desktop-Benutzer zur regelmäßigen Sicherung von Nutzerdaten. Eine gleichwertige Funktionalität kann über ein einfaches Skript (Abschnitt 10.2.2, „Ein Beispielskript für die Systemsicherung“) und cron(8) erreicht werden.

  • Bacula, Amanda und BackupPC sind voll ausgestattete Backup-Lösungen, die auf die regelmäßige Datensicherung über Netzwerk fokussiert sind.

Grundlegende Werkzeuge (in Abschnitt 10.1.1, „Archivierungs- und Kompressionswerkzeuge;“ und Abschnitt 10.1.2, „Kopier- und Synchronisationswerkzeuge;“ beschrieben) können verwendet werden, um Systemdatensicherungen über eigene Skripte durchzuführen. Solche Skripte können wie folgt erweitert werden:

  • Das obnam-Paket ermöglicht inkrementelle Datensicherungen (auch auf ferne Rechner).

  • Auch das rdiff-backup-Paket ermöglicht inkrementelle Datensicherungen (ebenfalls auf ferne Rechner).

  • Das dump-Paket hilft bei der inkrementellen und effizienten Archivierung und Wiederherstellung eines kompletten Dateisystems.

[Tipp] Tipp

Lesen Sie "/usr/share/doc/dump/" und "Is dump really deprecated?", um mehr über das dump-Paket zu lernen.

Bei einem privatem Debian-Arbeitsplatzsystem mit der Unstable-Suite muss ich lediglich persönliche und kritische Daten sichern. Ich installiere das System eh einmal im Jahr neu. Daher sehe ich keinen Grund, das komplette System zu sichern oder ein voll ausgestattetes Backup-Werkzeug zu installieren.

Ich verwende ein einfaches Skript, um ein Backup-Archiv zu erstellen und es über eine grafische GUI-Oberfläche auf CD/DVD zu brennen. Hier ein Beispiel für dieses Skript:

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
BUUID=1000; USER=osamu # UID and name of a user who accesses backup files
BUDIR="/var/backups"
XDIR0=".+/Mail|.+/Desktop"
XDIR1=".+/\.thumbnails|.+/\.?Trash|.+/\.?[cC]ache|.+/\.gvfs|.+/sessions"
XDIR2=".+/CVS|.+/\.git|.+/\.svn|.+/Downloads|.+/Archive|.+/Checkout|.+/tmp"
XSFX=".+\.iso|.+\.tgz|.+\.tar\.gz|.+\.tar\.bz2|.+\.cpio|.+\.tmp|.+\.swp|.+~"
SIZE="+99M"
DATE=$(date --utc +"%Y%m%d-%H%M")
[ -d "$BUDIR" ] || mkdir -p "BUDIR"
umask 077
dpkg --get-selections \* > /var/lib/dpkg/dpkg-selections.list
debconf-get-selections > /var/cache/debconf/debconf-selections

{
find /etc /usr/local /opt /var/lib/dpkg/dpkg-selections.list \
     /var/cache/debconf/debconf-selections -xdev -print0
find /home/$USER /root -xdev -regextype posix-extended \
  -type d -regex "$XDIR0|$XDIR1" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
find /home/$USER/Mail/Inbox /home/$USER/Mail/Outbox -print0
find /home/$USER/Desktop  -xdev -regextype posix-extended \
  -type d -regex "$XDIR2" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
} | cpio -ov --null -O $BUDIR/BU$DATE.cpio
chown $BUUID $BUDIR/BU$DATE.cpio
touch $BUDIR/backup.stamp

Dieses Beispielskript is dazu gedacht, als root ausgeführt zu werden.

Ich gehe davon aus, dass Sie es anpassen und wie folgt ausführen:

Halten Sie es einfach!

[Tipp] Tipp

Sie können die debconf-Konfigurationsdaten mit "debconf-set-selections debconf-selections" wiederherstellen und die dpkg-Paketauswahl mit "dpkg --set-selection <dpkg-selections.list".

Für eine Datensammlung in einem Verzeichnisbaum ermöglicht das Kopieren mit "cp -a" eine normale Datensicherung.

Für eine Sammlung von großen, nicht zu überschreibenden statischen Daten in einem Verzeichnisbaum wie der unterhalb des Verzeichnisses "/var/cache/apt/packages/" bieten harte Links mit "cp -al" eine Alternative zum normalen Backup bei effizienter Nutzung des Festplattenplatzes.

Hier ein Kopierskript für die Datensicherung, das ich bkup genannt habe. Dieses Skript kopiert alle Dateien im aktuellen Verzeichnis, die nicht unter Versionskontrolle stehen (nicht-VCS), in das Elternverzeichnis oder auf einen fernen Rechner.

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
fdot(){ find . -type d \( -iname ".?*" -o -iname "CVS" \) -prune -o -print0;}
fall(){ find . -print0;}
mkdircd(){ mkdir -p "$1";chmod 700 "$1";cd "$1">/dev/null;}
FIND="fdot";OPT="-a";MODE="CPIOP";HOST="localhost";EXTP="$(hostname -f)"
BKUP="$(basename $(pwd)).bkup";TIME="$(date  +%Y%m%d-%H%M%S)";BU="$BKUP/$TIME"
while getopts gcCsStrlLaAxe:h:T f; do case $f in
g)  MODE="GNUCP";; # cp (GNU)
c)  MODE="CPIOP";; # cpio -p
C)  MODE="CPIOI";; # cpio -i
s)  MODE="CPIOSSH";; # cpio/ssh
t)  MODE="TARSSH";; # tar/ssh
r)  MODE="RSYNCSSH";; # rsync/ssh
l)  OPT="-alv";; # hardlink (GNU cp)
L)  OPT="-av";;  # copy (GNU cp)
a)  FIND="fall";; # find all
A)  FIND="fdot";; # find non CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # user@remotehost.example.com
T)  MODE="TEST";; # test find mode
\?) echo "use -x for trace."
esac; done
shift $(expr $OPTIND - 1)
if [ $# -gt 0 ]; then
  for x in $@; do cp $OPT $x $x.$TIME; done
elif [ $MODE = GNUCP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU";cp $OPT . "../$BU/"
elif [ $MODE = CPIOP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU"
  $FIND|cpio --null --sparse -pvd ../$BU
elif [ $MODE = CPIOI ]; then
  $FIND|cpio -ov --null | ( mkdircd "../$BU"&&cpio -i )
elif [ $MODE = CPIOSSH ]; then
  $FIND|cpio -ov --null|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&cpio -i )"
elif [ $MODE = TARSSH ]; then
  (tar cvf - . )|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&& tar xvfp - )"
elif [ $MODE = RSYNCSSH ]; then
  rsync -aHAXSv ./ "${HOST}:${EXTP}-${BKUP}-${TIME}"
else
  echo "Any other idea to backup?"
  $FIND |xargs -0 -n 1 echo
fi

Dies sollen Befehlsbeispiele sein. Bitte lesen Sie das Skript und passen Sie es für sich selbst an, bevor Sie es nutzen.

[Tipp] Tipp

Ich habe dieses bkup in meinem "/usr/local/bin/"-Verzeichnis abgelegt. Ich führe es ohne jegliche Optionen im jeweiligen Arbeitsverzeichnis aus, wann immer ich ein temporäres Abbild des Verzeichnisses als Sicherung benötige.

[Tipp] Tipp

Um Abbilder inklusive der Historie von einem Quelldateibaum oder einem Konfigurationsdateibaum zu erstellen, ist es einfacher und bezüglich des Speicherplatzes effizienter, git(7) zu verwenden (lesen Sie dazu Abschnitt 10.6.5, „Git zur Aufzeichnung der Historie von Konfigurationsdateien“).

Die Sicherheitsinfrastruktur für Ihre Daten wird durch eine Kombination verschiedener Programme gewährleistet: Verschlüsselungswerkzeug, Message-Digest-Werkzeug und Signaturwerkzeug.


In Abschnitt 9.8, „Tipps zur Datenverschlüsselung“ finden Sie Infos über dm-crypto und ecryptfs, die automatische Datenverschlüsselungs-Infrastrukturen über Linux-Kernelmodule implementieren.

Hier einige Befehle für die grundlegende Schlüsselverwaltung mit GNU Privacy Guard:


Hier die Bedeutung des Vertrauenscodes:


Folgendes lädt meinen Schlüssel "1DD8D791" auf den populären Schlüsselserver "hkp://keys.gnupg.net" hoch:

$ gpg --keyserver hkp://keys.gnupg.net --send-keys 1DD8D791

Ein guter Standard-Schlüsselserver in "~/.gnupg/gpg.conf" (oder dem alten Ort "~/.gnupg/options") enthält folgendes:

keyserver hkp://keys.gnupg.net

Mit dem folgenden Befehl beziehen Sie unbekannte Schlüssel vom Schlüsselserver:

$ gpg --list-sigs --with-colons | grep '^sig.*\[User ID not found\]' |\
  cut -d ':' -f 5| sort | uniq | xargs gpg --recv-keys

Es gab einen Fehler in OpenPGP Public Key Server (Versionen vor 0.9.6), der Schlüssel mit mehr als zwei Unterschlüsseln korrumpierte. Das neue gnupg-Paket (>1.2.1-2) kann mit diesen korrumpierten Unterschlüsseln umgehen. Lesen Sie in gpg(1) den Abschnitt zur Option "--repair-pks-subkey-bug".

Hier einige Beispiele für die Verwendung von GNU Privacy Guard mit Dateien:


md5sum(1) enthält ein Werkzeug, um über die in RFC1321 beschriebene Methode eine Digest-Datei zu erzeugen und jede Datei darüber zu verifizieren:

$ md5sum foo bar >baz.md5
$ cat baz.md5
d3b07384d113edec49eaa6238ad5ff00  foo
c157a79031e1c40f85931829bc5fc552  bar
$ md5sum -c baz.md5
foo: OK
bar: OK
[Anmerkung] Anmerkung

Die Berechnung der MD5-Prüfsumme ist weniger CPU-intensiv als die für die krypthographische Signatur durch GNU Privacy Guard (GnuPG). Üblicherweise ist nur die Digest-Datei der obersten Ebene (z.B. das Wurzelverzeichnis eines Verzeichnisbaums) kryptographisch signiert, um die Datenintegrität sicherzustellen.

Es gibt viele Werkzeuge für die Zusammenführung von Quellcode. Folgende Befehle haben meine Aufmerksamkeit erregt:

Tabelle 10.10. Liste von Werkzeugen zur Quellcode-Zusammenführung

Paket Popcon Größe Befehl Beschreibung
diffutils V:814, I:945 1229 diff(1) Dateien Zeile für Zeile vergleichen
diffutils V:814, I:945 1229 diff3(1) drei Dateien Zeile für Zeile vergleichen und zusammenführen
vim V:148, I:379 2063 vimdiff(1) zwei Dateien nebeneinander in vim vergleichen
patch V:154, I:949 172 patch(1) eine diff-Datei auf ein Original anwenden
dpatch V:2, I:32 237 dpatch(1) Serien von Patches für Debian-Pakete verwalten
diffstat V:14, I:140 49 diffstat(1) eine Grafik der Veränderungen für eine diff-Datei erstellen
patchutils V:12, I:128 186 combinediff(1) einen kumulativen Patch aus zwei inkrementellen Patches erzeugen
patchutils V:12, I:128 186 dehtmldiff(1) ein Diff aus einer HTML-Seite extrahieren
patchutils V:12, I:128 186 filterdiff(1) Diffs aus einer Diff-Datei extrahieren oder entfernen
patchutils V:12, I:128 186 fixcvsdiff(1) von CVS erstellte Diff-Dateien, die patch(1) falsch interpretiert, reparieren
patchutils V:12, I:128 186 flipdiff(1) die Reihenfolge zweier Patches ändern
patchutils V:12, I:128 186 grepdiff(1) anzeigen, welche Dateien von einem Patch entsprechend einem regulären Ausdruck modifiziert werden
patchutils V:12, I:128 186 interdiff(1) Unterschiede zwischen zwei Unified-Diff-Dateien anzeigen
patchutils V:12, I:128 186 lsdiff(1) zeigen, welche Dateien von einem Patch verändert werden
patchutils V:12, I:128 186 recountdiff(1) Zähler und Offsets in vereinheitlichten Context-Diffs neu berechnen
patchutils V:12, I:128 186 rediff(1) Offsets und Zähler eines hand-editierten Diffs bereinigen
patchutils V:12, I:128 186 splitdiff(1) inkrementelle Patches aussortieren
patchutils V:12, I:128 186 unwrapdiff(1) Patches von fehlerhaften Zeilenumbrüchen befreien
wiggle V:0, I:0 189 wiggle(1) zurückgewiesene Patches anwenden
quilt V:7, I:57 794 quilt(1) Serien von Patches verwalten
meld V:9, I:44 2833 meld(1) vergleichen und zusammenführen von Dateien (GTK)
dirdiff V:0, I:5 191 dirdiff(1) Unterschiede zwischen Verzeichnissen anzeigen und zusammenführen
docdiff V:0, I:0 582 docdiff(1) zwei Dateien Wort-für-Wort / Buchstabe-für-Buchstabe vergleichen
imediff2 V:0, I:0 58 imediff2(1) interaktives Zweiwege-Zusammenführungs-Werkzeug mit Vollbildschirmmodus
makepatch V:0, I:0 148 makepatch(1) erweiterte Patch-Dateien erzeugen
makepatch V:0, I:0 148 applypatch(1) erweiterte Patch-Dateien anwenden
wdiff V:10, I:131 891 wdiff(1) Wort-für-Wort-Unterschiede zwischen Textdateien anzeigen

Hier eine Zusammenfassung der Versionskontrollsysteme (VCS) im Debian-System.

[Anmerkung] Anmerkung

Wenn Sie neu sind auf dem Gebiet der VCS-Systeme, sollten Sie damit beginnen, Git zu lernen, das auf der Beliebtheitsskala schnell steigt.


VCS ist teilweise auch bekannt als Revision Control System (RCS) oder Software Configuration Management (SCM).

Verteilte Versionskontrollsysteme (DVCS) wie Git sind das System der Wahl dieser Tage. CVS und Subversion könnten nach wie vor nützlich sein, um die Aktivitäten einiger vorhandener quelloffener Programme zu vereinen.

Debian stellt freie VCS-Dienste über Debian Alioth bereit. Alioth unterstützt praktisch alle VCS. Seine Dokumentation finden Sie unter http://wiki.debian.org/Alioth.

Es gibt einige Grundlagen für die Erstellung eines VCS-Archivs mit gemeinsamem Zugriff:

Hier eine sehr vereinfachte Gegenüberstellung nativer VCS-Befehle, um einen groben Überblick zu ermöglichen. Eine typische Befehlssequenz könnte weitere Optionen und Argumente erfordern.


[Achtung] Achtung

Der direkte Aufruf eines git-Unterbefehls mittels "git-xyz" über die Befehlszeile ist seit dem Frühjahr 2006 veraltet.

[Tipp] Tipp

Wenn eine ausführbare Datei namens git-foo in dem durch $PATH definierten Pfad existiert, wird dieser git-foo-Befehl ausgeführt, indem man "git foo" (ohne Bindestrich!) auf der Befehlszeile aufruft. Dies ist eine Funktionalität des git-Befehls.

[Tipp] Tipp

Grafische GUI-Werkzeuge wie tkcvs(1) und gitk(1) helfen Ihnen wirklich bei der Verfolgung der Vergangenheit von Dateien. Die Web-Oberfläche, die von vielen öffentlichen Archiven bereitgestellt wird, um die Depots mit einem Webbrowser zu durchsuchen, ist ebenfalls sehr nützlich.

[Tipp] Tipp

Git kann direkt mit verschiedenen VCS-Depots wie denen von CVS und Subversion umgehen; es bietet über die git-cvs- und git-svn-Pakete lokale Depots für lokale Änderungen. Lesen Sie dazu die gitcvs-migration-Handbuchseite sowie Abschnitt 10.6.4, „Git mit einem Subversion-Depot“.

[Tipp] Tipp

Git enthält Befehle, für die es in CVS und Subversion keine equivalenten Entsprechungen gibt: "fetch", "rebase", "cherry-pick", …

Git kann alles sowohl für die lokale wie auch für die ferne Quellcode-Verwaltung erledigen. Das bedeutet, dass Sie lokal alle Änderungen einpflegen können, ohne dazu eine Netzwerkverbindung zum fernen Depot zu benötigen.

Hier finden Sie weitere Informationen:

Die git-gui(1)- und gitk(1)-Befehle machen die Git-Nutzung sehr einfach.

[Warnung] Warnung

Nutzen Sie in der Tag-Zeichenkette keine Leerzeichen, auch wenn Werkzeuge wie gitk(1) dies ermöglichen. Andere git-Befehle könnten dadurch ins Stocken geraten.

Selbst wenn bei Ihnen Upstream ein anderes VCS verwendet, könnte es eine gute Idee sein, für lokale Aktivitäten git(1) zu nutzen, da Sie Ihre lokale Kopie eines Quellcodebaums ohne Netzwerkverbindung zum Upstream-Depot verwalten können. Hier einige Pakete und Pakete, die mit git(1) verwendet werden.


[Tipp] Tipp

Bei git(1) führen Sie viele Commits (Übernahme der Änderungen ins Depot) in einem lokalen Zweig (Branch) durch und nutzen später etwas wie "git rebase -i master", um die Änderungshistorie im Nachhinein neu zu organisieren. Dies erlaubt es Ihnen, eine saubere Änderungshistorie zu erstellen. Lesen Sie dazu git-rebase(1) und git-cherry-pick(1).

[Tipp] Tipp

Falls Sie zu einem sauberen Arbeitsverzeichnis zurückkehren möchten, ohne den aktuellen Status des Arbeitsverzeichnisses zu verlieren, können Sie "git stash" verwenden. Details finden Sie unter git-stash(1).

Mit Git-Werkzeugen können Sie die Historie von Konfigurationsdateien chronologisch aufzeichnen. Hier zur Übung ein einfaches Beispiel zur Aufzeichnung der Inhalte von "/etc/apt/":

$ cd /etc/apt/
$ sudo git init
$ sudo chmod 700 .git
$ sudo git add .
$ sudo git commit -a

Die Konfiguration mit einer Beschreibung einpflegen.

Machen Sie einige Änderungen an den Konfigurationsdateien.

$ cd /etc/apt/
$ sudo git commit -a

Übernehmen Sie dann die Konfiguration mit einer Beschreibung der Änderungen in das Git-Depot und fahren Sie mit Ihrer normalen Arbeit fort.

$ cd /etc/apt/
$ sudo gitk --all

Sie haben jetzt die vollständige Historie der Konfigurationsdateien vorliegen.

[Anmerkung] Anmerkung

sudo(8) wird benötigt, um jegliche Dateiberechtigungen von Konfigurationsdateien zu bearbeiten. Bei Konfigurationsdaten von Benutzern können Sie das sudo unter Umständen weglassen.

[Anmerkung] Anmerkung

Der Befehl "chmod 700 .git" im obigen Beispiel ist erforderlich, um die Archivdaten vor nicht authorisierten Lesezugriffen zu schützen.

[Tipp] Tipp

Falls Sie ein vollständigeres Setup für die Aufzeichnung der Historie von Konfigurationsdateien benötigen, schauen Sie sich das Paket etckeeper an: Abschnitt 9.2.10, „Aufzeichnen von Änderungen in Konfigurationsdateien“.

Hier finden Sie weitere Informationen:

  • cvs(1)

  • "/usr/share/doc/cvs/html-cvsclient"

  • "/usr/share/doc/cvs/html-info"

  • "/usr/share/doc/cvsbook"

  • "info cvs"

Viele öffentliche CVS-Server gestatten über den pserver-Dienst einen Nur-Lese-Zugriff für den Benutzer "anonymous". Zum Beispiel werden die Inhalte der Debian-Websites durch das webwml-Projekt via CVS über den Debian-Alioth-Service betreut. Mit folgendem Beispiel richten Sie "$CVSROOT" für den Fernzugriff auf dieses CVS-Depot ein:

$ export CVSROOT=:pserver:anonymous@anonscm.debian.org:/cvs/webwml
$ cvs login
[Anmerkung] Anmerkung

Da pserver für Abhörattacken und Unsicherheiten bekannt ist, wird der entsprechende Schreibzugriff gewöhnlich durch die Systemadministratoren deaktiviert.

Folgendes richtet "$CVS_RSH" und "$CVSROOT" für den Fernzugriff über SSH auf das CVS-Depot des webwml-Projekts ein:

$ export CVS_RSH=ssh
$ export CVSROOT=:ext:account@cvs.alioth.debian.org:/cvs/webwml

Sie können auch die Authentifizierung für SSH über einen öffentlichen Schlüssel aktivieren und so die Abfrage des Passworts unterbinden.

Hier ein Beispiel eines typischen Arbeitsablaufs bei CVS:

Überprüfen Sie alle verfügbaren Module aus dem CVS-Projekt, auf das "$CVSROOT" zeigt:

$ cvs rls
CVSROOT
modul1
modul2
...

Führen Sie einen Checkout von "modul1" in das Standard-Verzeichnis "./modul1" durch:

$ cd ~/pfad/zu
$ cvs co modul1
$ cd modul1

Führen Sie nötige Änderungen am Inhalt durch ...

Überprüfen Sie Ihre Änderungen über einen Befehl ähnlich zu "diff -u [depot] [lokal]":

$ cvs diff -u

Sie stellen fest, dass Sie eine Datei "file_to_undo" ernsthaft beschädigt haben, aber andere Dateien sind in Ordnung.

Überschreiben Sie die Datei "file_to_undo" mit der sauberen Kopie aus dem CVS, indem Sie folgendes ausführen:

$ cvs up -C file_to_undo

Sichern Sie den aktualisierten Quellcodebaum in das CVS-Depot:

$ cvs ci -m "Beschreibung der Änderungen"

Erzeugen Sie eine Datei "file_to_add" und fügen Sie sie zum CVS hinzu, wie folgt:

$ vi file_to_add
$ cvs add file_to_add
$ cvs ci -m "Datei file_to_add hinzugefügt"

Führen Sie die aktuellste Version aus dem CVS-Depot mit Ihrem lokalen Quellcode zusammen:

$ cvs up -d

Achten Sie auf Zeilen, die mit "C dateiname" beginnen; dies zeigt sich widersprechende Änderungen an.

Schauen Sie nach unverändertem Code in ".#dateiname.version".

Suchen Sie nach "<<<<<<<" und ">>>>>>>" in den Dateien, bei denen sich widersprechende Änderungen festgestellt wurden ("C dateiname").

Bearbeiten Sie die Dateien falls nötig, um Konflikte zu bereinigen.

Fügen Sie wie folgt eine Markierung (Tag) "Veröffentlichung-1" für die Version hinzu:

$ cvs ci -m "Letzte Änderungen für Veröffentlichung-1"
$ cvs tag Veröffentlichung-1

Weitere Änderungen

Entfernen Sie die "Veröffentlichung-1"-Markierung wie folgt:

$ cvs tag -d Veröffentlichung-1

Fügen Sie die Änderungen wie folgt zum CVS hinzu:

$ cvs ci -m "Wirklich letzter Commit für Veröffentlichung-1"

Fügen Sie die "Veröffentlichung-1"-Markierung erneut zum aktualisierten CVS HEAD hinzu:

$ cvs tag Veröffentlichung-1

Erzeugen Sie einen Zweig mit einer fixen Zweig-Markierung "initiale-Veröffentlichung-Fehlerkorrekturen" aus der originalen Version, auf die die Markierung "initiale-Veröffentlichung" zeigt, und führen Sie einen Checkout in das Verzeichnis "~/pfad/zu/alt" durch:

$ cvs rtag -b -r initiale-Veröffentlichung initiale-Veröffentlichung-Fehlerkorrekturen modul1
$ cd ~/pfad/zu
$ cvs co -r initiale-Veröffentlichung-Fehlerkorrekturen -d alt modul1
$ cd alt
[Tipp] Tipp

Verwenden Sie "-D 2005-12-20" (Datumsformat gemäß ISO 8601) statt "-r initiale-Veröffentlichung", um ein bestimmtes Datum für den Zeitpunkt des Zweigs festzulegen.

Arbeiten Sie mit diesem lokalen Quellcodebaum, der die Markierung "initiale-Veröffentlichung-Fehlerkorrekturen" hat und der auf der originalen Version beruht.

Arbeiten Sie selbst an diesem Zweig … bis jemand weiteres zu diesem "initiale-Veröffentlichung-Fehlerkorrekturen"-Zweig hinzustößt.

Synchronisieren Sie die Dateien mit von anderen veränderten Dateien dieses Zweigs und erzeugen Sie dabei falls nötig auch neue Verzeichnisse, wie folgt:

$ cvs up -d

Bearbeiten Sie die Dateien falls nötig, um Konflikte zu bereinigen.

Fügen Sie die Änderungen wie folgt zum CVS hinzu:

$ cvs ci -m "in diesen Zweig hinzugefügt"

Aktualisieren Sie den lokalen Quellcodebaum bei HEAD von main; dabei wird die fixe Zweig-Markierung entfernt ("-A") und es wird keine Tastatur-Expansion verwendet ("-kk"):

$ cvs up -d -kk -A

Aktualisieren Sie den lokalen Quellcodebaum (Inhalt = HEAD von main), indem Sie die Änderungen aus dem "initiale-Veröffentlichung-Fehlerkorrekturen"-Zweig (ohne Verwendung von Tastatur-Expansion) zusammenführen:

$ cvs up -d -kk -j initiale-Veröffentlichung-Fehlerkorrekturen

Beheben Sie Konflikte mit einem Editor.

Fügen Sie die Änderungen wie folgt zum CVS hinzu:

$ cvs ci -m "initiale-Veröffentlichung-Fehlerkorrekturen zusammengeführt"

Erstellen Sie ein Archiv, wie folgt:

$ cd ..
$ mv alt alt-modul1-korrekturen
$ tar -cvzf alt-modul1-korrekturen.tar.gz alt-modul1-korrekturen
$ rm -rf alt-modul1-korrekturen
[Tipp] Tipp

Dem Befehl "cvs up" kann die Option "-d" zur Erstellung neuer Verzeichnisse angehängt werden sowie "-P", um leere Verzeichnisse zu entfernen.

[Tipp] Tipp

Sie können einen Checkout von nur einem Unterverzeichnis von "modul1" durchführen, indem Sie seinen Namen angeben, z.B. "cvs co modul1/unterverz".


Subversion ist ein Versionskontrollsystem der aktuellen Generation, das das ältere CVS ersetzt. Es bietet die meisten Funktionalitäten von CVS, außer Markierungen (Tags) und Zweige (Branches).

Sie müssen die Pakete subversion, libapache2-svn und subversion-tools installieren, um einen Subversion-Server einzurichten.

Hier ein Beispiel eines typischen Arbeitsablaufs mit Subversion und seinem nativen Client.

[Tipp] Tipp

Client-Befehle, die durch das git-svn-Paket bereitgestellt werden, könnten durch die Nutzung von git einen alternativen Arbeitsablauf ermöglichen. Lesen Sie dazu Abschnitt 10.6.4, „Git mit einem Subversion-Depot“.

Überprüfen Sie wie folgt alle verfügbaren Module aus dem Subversion-Projekt, auf das die URL "file:///srv/svn/project" verweist:

$ svn list file:///srv/svn/project
modul1
modul2
...

Führen Sie einen Checkout von "modul1/trunk" in ein Verzeichnis "modul1" durch:

$ cd ~/pfad/zu
$ svn co file:///srv/svn/project/modul1/trunk modul1
$ cd modul1

Führen Sie nötige Änderungen am Inhalt durch ...

Überprüfen Sie Ihre Änderungen über einen Befehl ähnlich zu "diff -u [depot] [lokal]":

$ svn diff

Sie stellen fest, dass Sie eine Datei "file_to_undo" ernsthaft beschädigt haben, aber andere Dateien sind in Ordnung.

Überschreiben Sie die Datei "file_to_undo" mit einer sauberen Kopie aus Subversion:

$ svn revert file_to_undo

Sichern Sie den aktualisierten lokalen Quellcodebaum nach Subversion durch:

$ svn ci -m "Beschreibung der Änderungen"

Erzeugen Sie eine Datei "file_to_add" und fügen Sie sie zu Subversion hinzu:

$ vi file_to_add
$ svn add file_to_add
$ svn ci -m "Datei file_to_add hinzugefügt"

Führen Sie die aktuellste Version aus dem Subversion-Depot mit Ihrer lokalen Kopie zusammen:

$ svn up

Achten Sie auf Zeilen, die mit "C dateiname" beginnen; dies zeigt sich widersprechende Änderungen an.

Suchen Sie nach unveränderten Code-Teilen, z.B. in "filename.r6", "filename.r9" und "filename.mine".

Suchen Sie nach "<<<<<<<" und ">>>>>>>" in den Dateien, bei denen sich widersprechende Änderungen festgestellt wurden ("C dateiname").

Bearbeiten Sie die Dateien falls nötig, um Konflikte zu bereinigen.

Fügen Sie wie folgt eine Markierung (Tag) "Veröffentlichung-1" für die Version hinzu:

$ svn ci -m "Letzter Commit für Veröffentlichung-1"
$ svn cp file:///srv/svn/project/modul1/trunk file:///srv/svn/project/modul1/tags/Veröffentlichung-1

Weitere Änderungen

Entfernen Sie die "Veröffentlichung-1"-Markierung wie folgt:

$ svn rm file:///srv/svn/project/modul1/tags/Veröffentlichung-1

Sichern Sie Ihre Änderungen in das Subversion-Depot:

$ svn ci -m "Wirklich letzter Commit für Veröffentlichung-1"

Fügen Sie die "Veröffentlichung-1"-Markierung erneut aus dem aktualisierten Subversion-HEAD von trunk hinzu:

$ svn cp file:///srv/svn/project/modul1/trunk file:///srv/svn/project/modul1/tags/Veröffentlichung-1

Erzeugen Sie einen neuen Zweig mit dem Pfad "modul1/branches/initiale-Veröffentlichung-Fehlerkorrekturen" aus der originalen Version, auf die der Pfad "modul1/tags/initiale-Veröffentlichung" zeigt, und sichern Sie ihn in das "~/pfad/zu/alt"-Verzeichnis, wie hier:

$ svn cp file:///srv/svn/project/modul1/tags/initiale-Veröffentlichung file:///srv/svn/project/modul1/branches/initiale-Veröffentlichung-Fehlerkorrekturen
$ cd ~/pfad/zu
$ svn co file:///srv/svn/project/modul1/branches/initiale-Veröffentlichung-Fehlerkorrekturen alt
$ cd alt
[Tipp] Tipp

Verwenden Sie "modul1/trunk@{2005-12-20}" (Datumsformat gemäß ISO 8601) statt "modul1/tags/initiale-Veröffentlichung", um ein spezielles Datum für den Zeitpunkt des Zweigs festzulegen.

Arbeiten Sie weiter an dem lokalen Quellcodebaum, der auf "initiale-Veröffentlichung-Fehlerkorrekturen" verweist und der auf der originalen Version beruht.

Arbeiten Sie selbst an diesem Zweig … bis jemand weiteres zu diesem "initiale-Veröffentlichung-Fehlerkorrekturen"-Zweig hinzustößt.

Synchronisieren Sie die Dateien in diesem Zweig, die von anderen modifiziert wurden, wie hier:

$ svn up

Bearbeiten Sie die Dateien falls nötig, um Konflikte zu bereinigen.

Sichern Sie Ihre Änderungen in das Subversion-Depot:

$ svn ci -m "In diesen Zweig gesichert"

Aktualisieren Sie den lokalen Baum mit HEAD von trunk wie folgt:

$ svn switch file:///srv/svn/project/modul1/trunk

Aktualisieren Sie den lokalen Baum (Kontext = HEAD von trunk), indem Sie ihn mit dem Zweig "initiale-Veröffentlichung-Fehlerkorrekturen" zusammenführen:

$ svn merge file:///srv/svn/project/modul1/branches/initiale-Veröffentlichung-Fehlerkorrekturen

Beheben Sie Konflikte mit einem Editor.

Sichern Sie Ihre Änderungen in das Subversion-Depot:

$ svn ci -m "initiale-Veröffentlichung-Fehlerkorrekturen zusammengeführt"

Erstellen Sie ein Archiv, wie folgt:

$ cd ..
$ mv alt alt-modul1-korrekturen
$ tar -cvzf alt-modul1-korrekturen.tar.gz alt-modul1-korrekturen
$ rm -rf alt-modul1-korrekturen
[Tipp] Tipp

Sie können URLs wie "file:///…" durch jegliches andere URL-Format wie "http://…" oder "svn+ssh://…" ersetzen.

[Tipp] Tipp

Sie können einen Checkout von nur einem Unterverzeichnis von "modul1" durchführen, indem Sie seinen Namen angeben, z.B. "svn co file:///srv/svn/project/modul1/trunk/unterverz modul1/unterverz".