Archiv-Seite 2
Hier kommt mal wieder ein sehr nerviges Problem. Mein Szenario ist folgendes:
Man hat ein RAID 1 (Festplattenspiegelung), darin liegt eine mit LUKS verschlüsselte Partition. Dabei ist mindestens eine der RAID-Partitionen die einzige Partition der Festplatte. Nachdem man zunächst das RAID von Hand angelegt und dann alles getestet hat, trägt man die Daten für das RAID (welche man über mdadm --detail --scan bekommt) in die Datei /etc/mdadm/mdadm.conf ein. Nach dem nächsten Reboot läuft auch alles (scheinbar) ganz normal. Allerdings passiert nichts, wenn man mit
sudo cryptsetup luksOpen /dev/md0 [label]
sein verschlüsseltest Laufwerk aktivieren möchte. Es kommt nicht einmal eine Meldung. Hier hilft der Parameter -v:
edgar@atlantis: ~ $ sudo cryptsetup -v luksOpen /dev/md0 backup
Command failed with code 22: /dev/md0 is not a LUKS device.
Natürlich ist hier weder das Cryptolaufwerk noch LUKS kaputt, sondern das RAID. Vermutlich würde auch alles andere (z.B. mount) einen Fehler melden. Was genau kaputt ist liefert ein Blick in /proc/mdstat:
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[0] sdc[1]
488351744 blocks [2/2] [UU]
unused devices: none
Seht ihr den Unterschied? Ein Eintrag lautet “sdb1″, der andere nur “sdc”. mdadm hat aus versehen die gesamte Festplatte (/dev/sdc) als RAID-Device interpretiert und nicht die Partition (/dev/sdc1). Das ist sehr ärgerlich und lässt sich laut ubuntuusers dadurch vermeiden, dass man die Partition mindestens 128 KB kleiner macht als die Plattengröße.
Sicherer ist aber eine Definition in der /etc/mdadm/mdadm.conf. Der vordefinierte Eintrag “DEVICE partitions” allein hilft allerdings nicht. Man sollte die Partitionen entweder komplett für jedes RAID in der Form “DEVICE /dev/[partition1] /dev/[partition2]” angeben, oder aber einen Wildcard-Eintrag der Form “DEVICE /dev/hd*[0-9] /dev/sd*[0-9]” benutzen.
Achtung: Bei einem RAID sollte man immer zuerst prüfen, ob es korrekt zusammengebaut ist! Sobald man irgendwelche Tools wie z.B. fsck auf ein falsch gebautes RAID loslässt, gehen die Daten mit hoher Wahrscheinlichkeit verloren!
Angenommen man möchte von einer anderen Backup-Variante (z.B. rsnapshot, rsync, unison, cp, … ) auf rdiff-backup umsteigen. Dann hat man zumeist ein Datenverzeichnis, in dem eine Kopie der Originaldaten liegt. Jetzt wäre es schön, wenn man dieses “reine” Datenverzeichnis mit rdiff-backup in ein rdiff-backup-Ziel umwandeln könnte, ohne alle Dateien neu übertragen zu müssen*. Leider beschwert sich rdiff-backup aber, wenn man das vorhat:
Fatal Error: Destination directory
/mnt/backup/home
exists, but does not look like a rdiff-backup directory. Running
rdiff-backup like this could mess up what is currently in it. If you
want to update or overwrite it, run rdiff-backup with the --force
option.
Laut den alten Listenarchiven kann man die Option –force hier problemlos benutzen, um ein Verzeichnis mit rdiff-backup zu initialisieren. Die Daten werden dabei nicht komplett neu übertragen, sondern nur die Änderungen. Allerdings wird das Backup trotzdem recht lange dauern, weil rdiff-backup zuerst seine Datenbank erstellt und die Metadaten aller Dateien auslesen bzw. anlegen muss.
*: Ein ähnliches Szenario wäre es, wenn man das Backup über das Internet machen möchte. Dabei will man vermutlich zuerst den Datenbestand auf einer externen Festplatte übertragen (Initialbackup), damit man nicht alles über das Internet verschicken muss.
Bevor man lange Zeit mit Suchen vergeudet: es geht nicht. Zumindest nicht mit einfachen Mitteln. rsnapshot kann mit einem SSH-Server nur als Quelle umgehen, nicht als Ziel. Wenn man aber die Daten eines Desktoprechners per SSH auf einen Backupserver sichern möchte, kommt man mit rsnapshot nicht weit. Auch ein Weg über SSHFS (ein Verzeichnis auf einem SSH-Server lokal mounten) ist keine Lösung – es unterstützt nämlich die für rsnapshot essentiellen Hardlinks nicht.
Die einzige Möglichkeit die ich mir vorstellen kann, ist ein SSH-Tunnel: man baut mit
edgar@desktop: ~$ ssh -R 22222:localhost:22 backupserver
eine Verbindung zum Backupserver auf. Dabei wird auf backupserver der Port 22222 über den SSH-Tunnel auf Port 22 des lokalen Rechners (desktop) zurückgeschickt. Wenn man also mit
edgar@backupserver: ~$ ssh localhost -p 22222
eine SSH-Verbindung aufbaut, landet man auf dem Desktop-Rechner. Somit kann man auch rsnapshot auf dem Backupserver so konfigurieren, dass man als Quelle den localhost mit SSH über Port 22222 angibt. Da die Verbindung über den SSH-Tunnel an den Desktop-Rechner zurückgeschickt wird, ist dieser die Quelle für das Backup… Wer das mal getestet hat, möge mir einen Kommentar hinterlassen. :)
Da mir das ganze aber zu konfus war und rdiff-backup sowieso wesentlich speicherplatzeffizienter arbeitet als rsnapshot, steige ich nun auf rdiff-backup um. Da es bei der Umstellung aber auch Probleme geben kann, gibt es gleich einen weiteren Artikel.
Update: Es gibt eine nette Alternative zu rsnapshot. Im Wiki von Ubuntuusers gibt es ein Skript, welches sich ähnlich verhält wie rsnapshot, aber auch auf SSH-Server pushen kann. Man findet es hier: Backup_mit_RSYNC.
Dieser Fehler tritt eventuell auf, wenn man von Windows 7 auf eine Samba-Freigabe eines Linux-Rechners zugreifen möchte.
Im Internet findet man dazu einiges, vor allem Probleme der Samba-Konfiguration. Genaue Details zur korrekten Konfiguration gibt es beispielsweise hier: http://wiki.ubuntuusers.de/samba_server
Wenn ein Zugriff auf Samba trotz der korrekten Einrichtung der Samba-Konfigurationsdatei und der Samba-Benutzer nicht möglich ist, liegt vermutlich ein Rechteproblem vor. Hat der Benutzer, der über Samba auf die Freigabe zugreifen möchte, auch die Leserechte für die Datei? Auf Laufwerken mit Linux-Dateisystem lassen sich z.B. Leserechte für alle über den Befehl
sudo chmod -R o+r [ordnername]
hinzufügen. Mehr zum Thema Rechte unter Linux gibt es hier: http://wiki.ubuntuusers.de/rechte
Problematisch wird das ganze, wenn man auch noch eine Freigabe auf NTFS-Laufwerken haben möchte. Dabei muss man zusätzlich darauf achten, wie die Festplatte eingebunden (gemountet) ist. Hier ein Eintrag aus der Datei “/etc/fstab” meines Rechners:
UUID=7896C12A96C0E9A8 /mnt/Stuff ntfs rw,auto,user,nls=utf8,umask=007,gid=46 0 0
Wichtig ist hierbei der Eintrag “gid=46″. Er gibt nämlich an, dass das Laufwerk mit der Gruppe 46 (unter Ubuntu: “plugdev”) eingebunden wird. Damit dürfen nur Benutzer auf dieses Laufwerk (und damit auch auf die Freigabe!) zugreifen, die sich in der Gruppe “plugdev” befinden.
Das Problem wurde also dadurch behoben, den zugreifenden Benutzer nicht nur im Linux-System und unter Samba anzulegen, sondern ihn auch in die Gruppe “plugdev” aufzunehmen.
Willkommen zum Stapellauf meines Computer-Weblogs!
Hier werde ich in Zukunft Problemlösungen für diverse Computerprobleme veröffentlichen. Ein Augenmerk liegt dabei auf seltenen Problemen, also solche bei denen man längere Zeit suchen muss, um eine Lösung zu finden.
Dieses Weblog ersetzt die alte Homepage des implexus computerservice, welche unter wwwalt.implexus.de für Informationszwecke noch zu erreichen ist.
In diesem Sinne:
Happy Hacking!