Posts Tagged ‘rsync’

Dienstag, 16. Januar 2024

Ein für allemal: rsync, und die mühseligen Slashes

Ganz wichtig, und eigentlich ganz einfach, aber ich mache es immer falsch:

SOURCE Source is the directory that is backed up. At least one source is required. A trailing slash on a source path means „copy the contents of this directory“. Without a trailing slash it means „copy the directory“.

DESTINATION Destination is the directory that source is copied to. Trailing slash on the destination directory doesn’t matter.

Quelle: ‎rsync_tutorial‎.md

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. November 2017

rsync über SSH verwendet auf dem Zielsystem die falsche rsync-Version

Die Migration von meinem Mac mini auf einen iMac 27″ Retina schreitet stetig voran. Die Daten habe ich dazu mit rsync über Gigabit-Ethernet vom Mac mini auf den iMac rüberkopiert.

Der Befehl sah ungefähr so aus:

$ rsync --protect-args -avz -e ssh . mario@domain.tld:/tmp

Bei einem besonderen Verzeichnis trat (ungefähr) folgende Fehlermeldung auf (ich habe sie leider nicht festgehalten):

rsync: on remote machine: --extended-attributes: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.1]

Nach etwas Googlen realisiert ich, dass auf dem Zielsystem (dem iMac) zwar MacPorts mitsamt dem neuesten rsync längst installiert waren (/opt/local/bin/rsync mit rsync version 3.1.2 protocol version 31), über den ssh-Tunnel stattdessen aber das alte, von Apple mitgelieferte Binary verwendet wurde (/usr/bin/rsync mit rsync version 2.6.9 protocol version 29).

Der Grund: Wenn rsync einen SSH-Tunnel aufbaut, werden die üblichen Initialisierungsfiles von bash nicht geladen und somit auch die MacPorts-Pfade (/opt/local/...) nach Binaries abgesucht.

Abhilfe schafft man, indem man dem lokalen rsync mit dem Argument --rsync-path sagt, wo sich die gewünschte Binary befindet:

$ rsync --rsync-path=/opt/local/bin/rsync -av -e ssh . mario@domain.tld:/tmp

Quelle: How can I set environment variables for a remote rsync process?

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

curlftpfs unter Mac OS X

Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)

Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:

MacPorts

curlftpfs installiert man sich folgendermassen:

# port install curlftpfs

Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.

Geduldiges mounten

In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:

...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "

COUNTER=0
while [ ! -d "$SOURCE" ]
do
	let COUNTER=COUNTER+1
	echo -n "."
	
	if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
	then
		echo "Mountpoint still not available after $COUNTER iterations. Aborting."
		exit 1
	fi
done
...

In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.

Zugriff verweigert

Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?

Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):

$ curlftpfs -o defer_permissions ...

Zeichensalat

In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:

$ curlftpfs -o modules=iconv,from_code=latin1

Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71

Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.

Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:

$ iconv -l

In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 6. März 2014

rsync braucht unter Mac OS X ewig für „building file list…“

rsync ist das Tool meiner Wahl, um meine Backups auf mein Synology NAS im LAN sowie per WAN auf einen Linux-Server im Elternhaus zu spiegeln. Doch aufgepasst: Wer sich seit jeher daran stört, dass die Backup-Scripts bei hunderttausenden Dateien eine Ewigkeit bei „building file list…“ stehen bleiben, sei folgender Rat gegeben:

Man sollte unbedingt eine aktuelle Version von rsync – mindestens aber Version 3 – verwenden. Bis und mit Mac OS X 10.8 liefert Apple Version 2.6 mit, welche in dieser Hinsicht noch nicht optimiert wurde: Version 2 liest zuerst alle Dateien des Quellverzeichnis ein, während Version 3 nach den ersten 1000 Dateien (oder so) mit dem Backup beginnt und die verbleibenden Dateien anschliessend päckchenweise (nach Bedarf, basierend auf der Backup-Geschwindigkeit), einliest. Diese Massnahme verringert nebenbei auch gerade den RAM-Bedarf des Tools.

Version 3 ist auf meinem System über MacPorts installiert:

# port install rsync

Damit man auch wirklich sicher ist, dass in den eigenen Backup-Scripts Version 3 und nicht Version 2 verwendet wird, sollte man den rsync-Pfad in Scripts hardkodieren:

#RSYNC=$(which rsync)
RSYNC="/opt/local/bin/rsync/"

Um während der Ausführung eines Scripts zu prüfen, ob Version 3 des Tools verwendet wird, empfiehlt es sich, rsync das Argument --info=progress2 mitzugeben. In diesem Fall wird jede Datei, die kopiert wird, auf einer neuen Zeile ausgegeben. Neben dessen Grösse, dem Netzwerk-Durchsatz und der Transfergeschwindigkeit auf das Zielmedium steht ganz am Ende der Zeile einerseits xfr für die fortlaufende Nummer aller übertragender Dateien und Ordner sowie to-chk, die Zahl der bereits überprüften Dateien vom (provisorischen) Total aller Dateien. to-chk wird sich während der Laufzeit des Scripts sequentiell erhöhen.

$ rsync -av --info=progress2 . /mnt/backup/2014-03-06/
... 1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Shell-Scripte mit vielen Optionen

Komplexe Shell-Scripte, welche ein Unix-Tool mit unzähligen Optionen aufrufen, muss man ab und zu debuggen. Damit dies möglichst einfach funktioniert, habe ich mir angewöhnt, die Optionen so zu notieren, damit ich jede einzelne Option mit einem Tastendruck auskommentieren kann:

...
OPTS=""
OPTS="$OPTS --verbose"
OPTS="$OPTS --archive"
OPTS="$OPTS --no-owner"
OPTS="$OPTS --no-group"
#OPTS="$OPTS --delete" # WILL DESTROY EVERYTHING! DO NOT UNCOMMENT
OPTS="$OPTS --progress"
...
rsync $OPTS "$SOURCE" "$DESTINATION"
...

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 26. Januar 2014

Das Mac OS X Home-Verzeichnis mit rsync über SSH auf eine Synology Diskstation sichern

Nachdem ich den schlüsselbasierten Login hingekriegt hatte, stand ich bereits wieder vor dem nächsten Problem: Mein rsync-Script zur Sicherung meines Mac OS X Home-Verzeichnis in einen Unterordner auf meinem Home-Verzeichnis auf dem Synology NAS brach mit folgender Fehlermeldung ab:

...
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
ERROR: module is read only
...

Wieso denn das? Mit dem Synology-Konto meines Raspberry Pi klappt die ganze Chose problemlos!

Mit den Hinweisen unter Rsync over ssh: “ERROR: module is read only” suddenly appeared wurde ich auf den richtigen Pfad gelenkt: Ich musste meinem Benutzer mittels des Synology Web-GUIs Schreibrechte auf den Homes-Ordner geben:

  1. Control Panel
  2. Users
  3. %BENUTZER% auswählen
  4. Edit
  5. Privileges Setup
  6. homes
  7. [x] Read/Write
  8. OK

Seither klappt die rsync-Synchronisierung. Ob ich aber damit eine Sicherheitslücke geöffnet habe?

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. November 2013

(Aus dem Archiv) Backup my Mac OS X home directory with rsync

Der vorliegende Artikel habe ich ursprünglich irgendwann einmal ab 2002 auf meinem damaligen Linux-Entwicklungsserver im Web publiziert. Da ich das bloggen erst 2005 entdeckt habe, waren die Tipps in einer grossen HTML-Seite untergebracht. Anlässlich einer Aufräumaktion auf dem Server habe ich mich entschieden, die „Perlen“ über meine heutige Kommunikationsplattform ins Web zu posaunen. Seitdem ich die Artikel verfasst habe, sind viele Tage ins Land gegangen — ob der Artikel noch Gültigkeit hat, entscheidet der geneigte Leser selber.

Please be aware to use the special rsync-Version written for Mac OS X (fucking resource forks, again!). Otherwise you could end up with a mess (only on the backup side, but this sucks as much!).

I separated iPhoto-Files from the rest, because the .sparseimage wouldn’t fit on a DVD anylonger.

backup.sh

#!/bin/sh

if [ $# -lt 1 ]
then
	echo "Please provide a destination to store the backup to:"
	echo "fwdsk (Firewire-Drive)"
	echo "eth (Server-Share)"
	echo "tmp (/tmp)"
	exit 1
fi

case $1 in
	"fwdsk")
		IMAGEFOLDER="/Volumes/TRANSFER";;
	"eth")
		IMAGEFOLDER="/Volumes/RSYNC";;
	"tmp")
		IMAGEFOLDER="/tmp";;
	*)
		echo "Please provide a destination to store the backup to:"
		echo "fwdsk (Firewire-Drive)"
		echo "eth (Server-Share)"
		echo "tmp (/tmp)"
		exit 1;;
esac

if [ ! -d "$IMAGEFOLDER" ]
then
	echo "Directory '$IMAGEFOLDER' not found"
	exit 1
fi

BACKUPINFO=( "home" "iphoto" )

for VOLNAME in ${BACKUPINFO[@]}
do
	DISKIMAGENAME="$VOLNAME"
	DISKIMAGEPATH="$IMAGEFOLDER/$VOLNAME.sparseimage"
	
	BACKUPSOURCEFILE="/Users/mario/Rsync/bkpsrc/$VOLNAME.txt"
	
	if [ ! -f "$BACKUPSOURCEFILE" ]
	then
		echo "File '$BACKUPSOURCEFILE' not found"
		exit 1
	fi
	
	BACKUPSOURCE=`more $BACKUPSOURCEFILE`
	BACKUPDESTINATION="/Volumes/$VOLNAME"
	RSYNCEXCLUDE="/Users/mario/Rsync/exclude/$VOLNAME.txt"
	
	#-------------------------------------------------
	# Create/reuse & mount Disk-Image
	#-------------------------------------------------
	if [ ! -f "$DISKIMAGEPATH" ]
	then
		# Disk-image-file doesn't even exist - create it
		echo "Creating disk image \"$DISKIMAGEPATH\""
		hdiutil create -fs HFS+ -type SPARSE -size 20g -volname "$DISKIMAGENAME" "$DISKIMAGEPATH"
	else
		echo "Using pre-existing disk image \"$DISKIMAGEPATH\""
	fi
	
	if [ ! -d "$BACKUPDESTINATION" ]
	then
		# Disk-image doesn't seem to be mounted
		hdiutil attach "$DISKIMAGEPATH"
	fi
	
	#-------------------------------------------------
	# Did Disk-Image mount correctly?
	#-------------------------------------------------
	if [ ! -e "$BACKUPDESTINATION" ]
	then
		echo "There was a problem creating or mounting the disk image"
		exit 1
	fi
	
	#-------------------------------------------------
	# Rsync
	#-------------------------------------------------
	/Users/mario/Rsync/rsync.sh "$BACKUPSOURCE" "$BACKUPDESTINATION" "$RSYNCEXCLUDE"
	
	#-------------------------------------------------
	# Unmount Disk-Image and do maintenance operations
	#-------------------------------------------------
	# hdiutil info | grep /Volumes/$VOLNAME | cut -f 1
	# 
	# Expected output: /dev/disk2s2    Apple_HFS       /Volumes/Rsync-Backup
	#                  ^ this info is required to unmount
	
	DISKIMAGEDEVICE=`hdiutil info | grep /Volumes/$VOLNAME | cut -f 1`
	echo "Disk image mounted as $DISKIMAGEDEVICE"
	
	hdiutil detach -quiet "$DISKIMAGEDEVICE"
	echo "Disk image ejected"
	
	hdiutil compact "$DISKIMAGEPATH"
	echo "Disk image compacted"
done

rsync.sh

#!/bin/sh

if [ $# -ne 3 ]
then
	echo "Usage:"
	echo "rsync.sh   "
	exit 1
fi

BACKUPSOURCE="$1"
BACKUPDESTINATION="$2"
RSYNCEXCLUDE="$3"

if [ ! -d "$BACKUPSOURCE" ]
then
	echo "Source directory '$BACKUPSOURCE' not found"
	exit 1
fi

if [ ! -d "$BACKUPDESTINATION" ]
then
	echo "Destination directory '$BACKUPDESTINATION' not found"
	exit 1
fi

if [ ! -f "$RSYNCEXCLUDE" ]
then
	echo "Exclude file '$RSYNCEXCLUDE' not found"
	exit 1
fi

# --verbose
# --showtogo
# --dry-run
time sudo /usr/local/bin/rsync -a --delete --delete-excluded --eahfs --showtogo --exclude-from\
 "$RSYNCEXCLUDE" "$BACKUPSOURCE" "$BACKUPDESTINATION"

bkpsrc/home.txt

/Users/mario/.

bkpsrc/iPhoto.txt

/Users/mario/Pictures/iPhoto Library/.

exclude/home.txt

Music/
Movies/
PoisonDownloads/
Cache/
Caches/
.Trash/
Fun-Stuff/
.DS_store
iPhoto Library/

exclude/iphoto.txt

.Trash/
.DS_store

Tags: ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. September 2013

Den Raspberry Pi mit rsync über SSH auf die Synology DiskStation sichern

Als Gedankenstütze nachfolgend einige Lösungen für Probleme, die sich mir in den Weg stellten:

Mac OS X

$ ssh-keygen -t rsa -b 2048 -f id_rsa_dashboard_vault

Die Aufforderung, ein Passwort für den Private Key zu generieren, bestätigt man mit ENTER — der Private Key wird so nicht zusätzlich mit einem Passwort geschützt, weil dies den automatisierten Login von Raspberry Pi auf die DiskStation verhindern würde.

Der Befehl erstellt zwei Dateien:

  • id_rsa_dashboard_vault
  • id_rsa_dashboard_vault.pub

Synology DiskStation

Als erstes richtet man sich über die Web-Oberfläche einen normalen Benutzer dashboard ein, in dessen Home-Verzeichnis die Backup-Daten geschrieben werden.

Hierzu müssen dem Benutzer Schreibrechte auf /homes gegeben werden. Ansonsten sieht man sich beim Starten des Backup-Scripts (s. unten) mit folgender Fehlermeldung gegenüber:

ERROR: module is read only

Quelle: Rsync over ssh: “ERROR: module is read only” suddenly appeared

Wichtig ist weiter, dass der SSH-Zugang über die Web-Oberfläche aktiviert wurde.

/etc/passwd

Dem neu erstellten Benutzer müssen wir nun eine gültige Login-Shell zuweisen:

...
dashboard:x:1029:100::/var/services/homes/dashboard:/bin/ash

Erfasst man hier ein nicht existierendes Login-Shell, kriegt man beim Debugging des publickey SSH-Logins folgende komische Infos ans Gesicht geworfen:

...
Authentication succeeded
...
Permission denied
...

Um sicher zu gehen, dass die Login-Shell richtig konfiguriert ist, macht man als auf der DiskStation eingeloggter User root folgendes:

# su dashboard

Wechselt man in ein neues Shell, ist /etc/passwd korrekt konfiguriert.

/var/services/homes/dashboard/.ssh/authorized_keys

In dieser Datei legen wir den Public Key ab (id_rsa_dashboard_vault.pub).

/etc/ssh/sshd_config

Wahrscheinlich müsste man hier gar nichts anpassen, beim Debugging habe ich es dann doch getan (wohl unnötigerweise):

$ cat sshd_config | grep -v "^#" | sort
AllowTcpForwarding no
AuthorizedKeysFile	.ssh/authorized_keys
ChallengeResponseAuthentication no
ChrootDirectory none
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_rsa_key
LogLevel INFO
Match User root
    AllowTcpForwarding yes
Protocol 2
PubkeyAuthentication yes
Subsystem       sftp    internal-sftp -f DAEMON -u 000
SyslogFacility AUTH
UseDNS no
UsePAM yes

Raspberry Pi

/root/.ssh/config

Host vault
   Hostname 10.0.44.44
   User dashboard
   IdentityFile ~/.ssh/id_rsa_dashboard_vault

In der Datei ~/.ssh/id_rsa_dashboard_vault legt man den Private Key ab.

Login überprüfen

Dies sollte nun ohne Eingabe eines Passwortes möglich sein:

$ ssh vault

Bei einer Fehlermeldung helfen die Optionen -v, -vv und -vvv weiter:

$ ssh -v vault

/usr/local/bin/backup.sh

Folgendes Script sichert / (root) des Raspberry Pis auf den Host vault in den Pfad /volume1/homes/dashboard/backups/. Auf dem Raspberry Pi nicht mehr vorhandene Dateien werden auf der DiskStation gelöscht.

#!/bin/sh

RSYNC=`which rsync`

if [ ! -e "$RSYNC" ]
then
	echo "rsync binary not found: '$RSYNC'"
	exit 1
fi

TODAY=`date +"%F_%T"`
SNAPSHOTFILE="/var/log/rsync/$TODAY.snapshot.txt"
#touch "$SNAPSHOTFILE"
echo "$TODAY" > "$SNAPSHOTFILE"

if [ ! -f "$SNAPSHOTFILE" ]
then
	echo "Could not create snapshotfile '$SNAPSHOTFILE'"
else
	echo "Snapshotfile created at:"
	ls -l "$SNAPSHOTFILE"
fi

LOGFILE="/var/log/rsync/$TODAY.log.txt"
EXCLUDEFILE="/usr/local/bin/backup-exclude.txt"

SOURCE="/"
DEST="vault:/volume1/homes/dashboard/backups/"

echo "Running rsync ..."
$RSYNC -avz --log-file="$LOGFILE" --exclude-from="$EXCLUDEFILE" --delete -e ssh "$SOURCE" "$DEST" 
echo "Backup complete."

exit 0

/usr/local/bin/backup-exclude.txt

proc/*
sys/*
dev/*
tmp/*
run/*
mnt/*

Quelle: Can a Raspberry Pi be used to create a backup of itself?

/etc/crontab

...
4 0 * * *	root	/usr/local/bin/backup.sh

Hiermit wird das Backup-Script täglich um 4 Uhr morgens ausgeführt.

Links

Tags: , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 7. Juli 2013

Debian-Installation auf eine SSD-Festplatte migrieren

Auf Grund eines längeren Ausfalls meines Servers (Gründe: Netzteil des Cablemodems ist gestorben, Switch auf Grund eines Wackelkontaktes des Netzteils ohne Strom) war ich heute im Elternhaus. Aus gegebenem Anlass habe ich mich entschieden, die Debian-Installation von einer Samsung HD161GJ (160GB) auf eine hier unbenutzt herumliegende 128GB SSD–Festplatte (Crucial M4-CT128M4SSD2) zu migrieren.

Nachfolgend eine Schritt-für-Schritt-Anleitung, wie dieses Vorhaben in möglichst kurzer Zeit bewerkstelligt werden kann.

Grob (für Profis)

  1. Zweite Festplatte an Server anschliessen (SATA oder via USB-Adapter)
  2. SSD-Festplatte partitionieren (bei mir: /boot, Swap und / (root))
  3. SSD-Partitionen formatieren (mkfs.ext4, mkswap)
  4. Partitionen mounten
  5. Mittels rsync alle Nutzdaten von den System-Partitionen auf die SSD-Partionen verschieben
  6. Die UUIDs in /etc/fstab der SSD-Festplatte anpassen
  7. grub-install auf die SSD-Festplatte
  8. Herunterfahren
  9. Ehemalige System-Platte vom System trennen
  10. Neu starten
  11. BIOS anpassen
  12. grub rescue überreden, von der SSD-Festplatte zu starten, obwohl die UUIDs nicht mehr stimmen
  13. update-grub ausführen

Detailliert (für Anfänger/Erfahrene)

Partitionierung

Nachdem die Festplatte erfolgreich an den SATA-Bus angeschlossen worden ist, sollte sie sowohl unter /var/log/messages als auch mittels fdisk -l aufgelistet werden. Den von dort übernommenen Device-Namen (in meinem Fall: /dev/sdd) verwendet man, um das Partitionierungstool fdisk zu starten:

# fdisk /dev/sdd

Ich habe mir zuerst eine primäre Partition für /boot erstellt (p, 1024MB) und die Partition bootbar gemacht (a). Anschliessend habe ich eine erweiterte Partition erstellt, in welcher ich einerseits eine Swap-Partition erstellt habe (Typ 82, 1024MB — so gross wie der verfügbare RAM-Speicher) als auch die root-Partition.

Ganz wichtig ist, alle Änderungen am Schluss mittels w auch effektiv auf die SSD zu schreiben.

Formatierung

Die Formatierung ist schnell erledigt. Mittels mkfs.ext4 formatiert man die /boot-Partition:

# mkfs.ext4 /dev/sdd1

… als auch die / (root)-Partition:

# mkfs.ext4 /dev/sdd6

Mittels mkswap formatiert man die Swap-Partition:

# mkswap /dev/sdd5

Mounten

Solange man die /etc/fstab-Einträge noch nicht umgebogen hat, müssen /boot und / (root) manuell gemountet werden:

# mount /dev/sdd1 /mnt/neu/boot
# mount /dev/sdd6 /mnt/neu/root

Der Filesystem-Typ wird automatisch erkannt.

Filesystem klonen

Die beiden Partitionen klont man folgendermassen:

# cd /
# rsync -av --one-file-system . /mnt/neu/root
# cd /boot
# rsync -av --one-file-system . /mnt/neu/boot

fstab

Die fstab-Datei muss auf der neuen / (root)-Partition angepasst werden. Die Festplatten sollte man heutzutage mit den UUIDs ansprechen. Die UUIDs findet man mit dem Befehl blkid heraus:

...
/dev/sdd1: UUID="3993c6e2-de5c-4227-9cae-637bbfc820b7" TYPE="ext4" 
/dev/sdd5: UUID="79c00de9-06a7-41e5-a470-641b5f68b909" TYPE="swap" 
/dev/sdd6: UUID="9672eb79-b6da-4192-a507-45de2662af2d" TYPE="ext4"
...

Die Partitionen definiert man basierend darauf folgendermassen in /etc/fstab:

...
#/etc/fstab: static file system information.
#
# 												
UUID=3993c6e2-de5c-4227-9cae-637bbfc820b7	/boot		ext4	discard,noatime,errors=remount-ro	0	2
UUID=79c00de9-06a7-41e5-a470-641b5f68b909	none		swap	sw					0	0
UUID=9672eb79-b6da-4192-a507-45de2662af2d       /               ext4    discard,noatime,errors=remount-ro       0       1
...

Gemäss SSD-Fetischisten sind die Optionen discard,noatime unendlich wichtig, um die Lebensdauer der SSD-Festplatte von 19 auf 19.1 Jahre zu erhöhen … Randbemerkung: Die SSD-Optimierer erscheinen mir ähnlich suspekt wie die Idioten, welche bei jedem Mac-Problem erst einmal raten, Repair Permissions durchzuführen (Richtigstellung: Seriously, ‘Repair Permissions’ Is Voodoo).

grub installieren

Mittels folgendem Befehl wird der grub Bootloader in den MBR der neuen Festplatte geschrieben:

# grub-install /dev/sdd

ACHTUNG: Viele Web-Seiten raten in diesem Schritt, den Computer von einer Linux Live-CD zu starten, mittels chroot das Root des Systems auf die SSD-Festplatte umzubiegen sowie sys, proc und dev neu zu mounten. Wer den hier notierten Anweisungen folgt, kann sich diesen umständlichen Schritt sparen.

BIOS

In meinem Fall war im BIOS hardkodiert, dass die 160 GB-Platte von Samsung die zu bootende Festplatte war. Da diese nun fehlte, blieb das System ohne Fehlermeldung hängen. Im BIOS musste ich deshalb die SSD-Festplatte neu als Boot-Festplatte aufnehmen.

grub rescue

Da ich grub-install ausgeführt hatte, als Linux noch von der Samsung-Festplatte als Systemplatte lief, wurden die UUIDs der Partitionen dieser Festplatten in den grub-MBR der SSD-Festplatte geschrieben.

Als das BIOS den Bootloader von der SSD-Platte startete, erschien folgende Fehlermeldung auf dem Schirm:

No such Device: ad4103fa-d940-47ca-8506-301d8071d467

Mittels des Befehls ls wurden mir alle erkannten Festplatten und Partitionen angezeigt. Nachdem ich die System-Festplatte in der grub-Nomenklatur ausgemacht hatte, konnte ich grub mitteilen, wie es zu starten hatte:

set prefix=(hd0,msdos0)/grub
set root=(hd0,msdos5)
insmod normal
normal

Mit diesen Angaben fand grub die Partitionen mit den benötigten Boot-Informationen und Debian startete sauber — und dank SSD blitzschnell.

grub

Da das System nun von SSD-Festplatte lief, konnte ich grub-install erneut ausführen. Dieses Mal übernahm grub die UUIDs der SSD-Partitionen, was ich mir mit update-grub bestätigen liess. Der letzte Befehl schrieb die grub-Konfiguration im Klartext in die Datei /boot/grub/grub.cfg.

Links

Tags: , , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen