• blaues Gehäuse statt schwarz (zwecks Unterscheidbarkeit)
• kleinere 250mA Batterie, die 1400mAh des Webservers sind für eine USV überdimensioniert.
• T2 Prozessor statt dem A20. T hat einen größeren Temperaturbereich (Industrieausführung), ansonsten ident. T hat es zum Zeitpunkt als ich den Webserver kaufte noch nicht gegeben.

Die externen Festplatten werden am oberen USB Port 1, der 1000 mA liefert, angeschlossen. Der untere Port 2 liefert nur 523mA und ist daher zu schwach.

UAS funktioniert mit den Seagate Platten und dem Linux Kernel nicht zuverlässig und musste deaktiviert werden:

$ cat /etc/modprobe.d/blacklist_uas.conf
options usb-storage quirks=0bc2:ab28:u

Im Olimex Kernel 5.10.180-olimex ist usb-storage nicht als Modul kompiliert, sonder statisch. Daher muss UAS mit Linux-Boot Kommandozeilenparametern deaktiviert werden. Dazu mit einem seriellen Kabel und screen Terminal booten

$ screen /dev/ttyUSB0 115200

und eine beliebige Taste drücken und in der u-boot Kommandozeile das einstellen:

$ setenv bootargs 'usb-storage.quirks=0bc2:ab28:u,059f:1093:u,1058:2621:u,0bc2:203a:u'
$ saveenv                                                                             

Im gestarteten Linux kann überprüft werden ob es funktioniert hat mit:

$ cat /proc/cmdline                                                                   

Die WD Platten funktionieren mit uas.

Die Platten sind mit dm-crypt/luks verschlüsselt und mit ext4 Dateisystem formatiert. Es ist wichtig die Verschlüsselung und Formatierung auf dem A20 und nicht auf einem Laptop oder anderem Gerät mit mehr RAM zu machen, weil cryptsetup die RAM Größe bei luksFormat ermittelt und dann auch wieder für die Verschlüsselung braucht. Es kann also passieren, dass ein Gerät das mit viel RAM verschlüsselt wurde auf einem Gerät mit wenig Ram nicht mehr entschlüsselbar ist. siehe Zwecks Unterscheidbarkeit haben die Festplatten unterschiedliche Gehäusefarben, das Kaufdatum / Garantiezeit und Händler wird darauf notiert.

Zuerst wurden 2 Platten verwendet, aber später auf 3 geändert, da bei Defekten einer Platte eine neue mit den Daten kopiert werden muss und das Tage dauern kann, währenddessen kein Backup möglich ist. Mit 3 Platten gibt es keine Unterbrechungen des Backups wenn eine Platte defekt wird.

Das Schreiben einer kompletten 4 TB HDD dauert ca. 1,5 Tage. Das Datei basierte kopieren einer verschlüsselten 4 TB Platte dauert bis zu 3 Tage, da sie zuerst auch mit /dev/zero überschrieben werden muss und dann die Daten kopiert.

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX encrypted-external-drive
dd if=/dev/zero of=/dev/mapper/encrypted-external-drive bs=64K status=progress
mkfs.ext4 /dev/mapper/encrypted-external-drive
mount /dev/mapper/encrypted-external-drive /tmp/neue_hdd
rsync --info=progress2 -a /tmp/alte_hdd/rsnapshot /tmp/neue_hdd/

Alternativ ist bitweises Kopieren mit dd und ändern der UUID's möglich. Wichtig ist, dass die neue Platte gleich groß oder größer ist als die alte von der kopiert wird. Achtung: auch nominal gleich große Platten können eine unterschiedliche Anzahl Bytes haben. Daher beide Platten prüfen mit:

$ fdisk -l /dev/mapper/seagate 
Festplatte /dev/mapper/seagate: 3,64 TiB, 4000770252288 Bytes, 7814004399 Sektoren
$ fdisk -l /dev/mapper/wdneu 
Festplatte /dev/mapper/wdneu: 3,64 TiB, 4000735821824 Bytes, 7813937152 Sektoren

• Kopieren:

Prüfen Devicenamen: dmesg in watch Modus und Platten nacheinander einstecken

$ sudo dmesg -w

• Klonen:

dd if=/dev/sdX of=/dev/sdY bs=32M status=progress

• Ändern UUID's:

der Luks Partition:

cryptsetup luksUUID /dev/sdc --uuid 8170ad52-0aac-4d1a-adaf-d15dca28dabb

des Dateisystems, e2fsck ist vorher notwendig, Achtung: tune2fs ist sehr langsam

e2fsck -f /dev/mapper/wdneu
tune2fs /dev/mapper/wdneu -U 4efafebc-966a-4caa-9907-e5f3427ccd5c

Die Seagate Consumer Platten haben beide leider nur ein paar Jahre gehalten und auch die Lacie Rugged Platte war innerhalb der Garantiezeit von 3 Jahren defekt. Auch eine WD Elements SE Platte war bald defekt. Eine weitere WD Elements ist nach einem halben Jahr defekt geworden. Um Komplettausfälle aufgrund von Serienfehlern zu vermeiden ist es ratsam verschiedenste Hersteller / Typen für die Platten zu verwenden und auf eine lange Garantiezeit zu achten. Die Firma e-tec war erst nach Drohung mit Gewährleistung bereit nach Monaten interner Prüfung der beanstandeten Platte diese zu tauschen. Sie behaupten die Garantiezeit verlängert ein Tausch nicht. Sie ließen mich bei der Abholung einen Übernahmezettel unterschreiben ohne Hinweis auf den Vorbehalt zur Nachverrechnung im Kleingedruckten. Mediamarkt hat die Platte sofort anstandslos und unkompliziert im Markt umgetauscht.

Ein Wechsel/Versuch auf SSD ist noch ausständig.

Ursprünglich 1 x vorhandene interne SATA HDD 320 GB Samsung HM329JI.

Im Jänner 2021 wurde eine neue SSD (SSD-WD-WDS120G2G0A Green SSD WDS120G2G0A, 120GB SSD, intern, 2.5" (6.4 cm), SATA 6Gb/s) eingebaut, und das Betriebssystem darauf neu installiert, da die microSD Karte defekt wurde.

Installiert wurde wie auf dem Webserver Standard Debian Stretch, allerdings mit unverschlüsselter Root Partition ursprünglich auf der SD/MMC1 microSD Karte und dem von Olimex mit deren Image mitgelieferten u-boot. Von dem größeren SD/MMC2 SD Karten Schacht ist leider kein Betriebssystemstart möglich. (von Olimex dokumentiert)

Leider ist diese microSD Karte im Jänner 2021 defekt geworden, sodass eine Neuinstallation auf einer neuen SATA SSD notwendig war. u-boot blieb auf einer neuen microSD Karte. Es wurde wieder Debian Oldstable (Stretch) installiert, weil unter Buster cryptsetup mit aes-xts-plain64 cipher für die externen Platten aufgrund eines Bugs nicht funktionierte.

Diverse Absicherungen des Servers wurden konfiguriert / installiert.

Um ein versehentliches Schreiben auf das nicht eingehängte Mount-Verzeichnis der externen Platte und damit ein Vollschreiben der Root Partition zu vermeiden, wurde das Verzeichnis mit chattr schreibgeschützt.

Zur Erhöhung der Sicherheit und um Strom zu sparen werden die externen USB Platten vor dem Backup eingeschaltet und nach dem Backup wieder komplett abgeschaltet:

$ cat /usr/local/bin/mount-exthdd
#!/bin/bash
# exit 2
source getbkpdev
source lockwait

timeout=30 # seconds to wait for the device appearing
lockfile=/var/lock/mount-exthdd.lock

lockwait $lockfile 10 60

trap "rm -f ${lockfile}; exit" INT TERM EXIT
echo $$ > ${lockfile}

if mount | grep "/dev/mapper/exthdd_crypt" > /dev/null; then
    exit 0;
fi

if ! get_dev >/dev/null ; then
    # probably before powered off usb device, reload kernel module to turn it on again
    rmmod ehci_platform
    modprobe ehci_platform

    # wait for the device to appear
    i=0
    until get_dev > /dev/null ; do
	sleep 10
	let "i++"
	if [ $i -eq $timeout ]; then
	    echo "timout searching for the device waited times: $i"
	    exit 1
	fi
	# echo "waiting... nr $i"
    done
fi

if ! get_dev > /dev/null; then
    echo "unable to find backup device" 1>&2
    exit 1
fi

cryptsetup luksOpen $(get_dev) exthdd_crypt --key-file=xxxx

if [ $? ]; then
  mount /dev/mapper/exthdd_crypt /mnt/exthdd
fi

$ cat /usr/local/bin/lockwait

function dbg {
    # logger -id "$srcname.lockwait" -p syslog.debug "$1"
    # echo $1
    }

function lockwait () {
    lockfile=$1
    sleeptime=$2
    timeout=$3
    scrname=$(echo $0 | awk -F "/" '{print $NF}')

    if [ -f $lockfile ]; then
	PID=$(cat $lockfile)
	dbg "lockfile $lockfile : andere PID=$PID eigene=$$"
	if [ $PID -ne $$ ]; then
	    if kill -0 $PID; then
		t="waiting for '$lockfile' pid: $PID"
		logger -id $scrname -p syslog.info "$t"
		dbg "$t"
		i=0
		while ps -p $PID >/dev/null 2>&1
		do
		    dbg "sleep $sleeptime nr $i"
		    sleep $sleeptime
		    let "i++"
		    if [ $i -eq $timeout ]; then
			t="timeout waiting for '$lockfile' pid: $PID"
			logger -id $scrname -p syslog.err $t
			dbg "$t"
			exit 1
		    fi
		done
		dbg "$PID nicht mehr da"
	    fi
	fi
    else
	dbg "lockfile $lockfile nicht vorhanden"
    fi
}

$ cat /usr/local/bin/getbkpdev
#!/bin/bash

dev_schwarz=/dev/disk/by-uuid/xxxxxxx-xxxx-xxx-xxxx-xxxxxx
dev_silber=/dev/disk/by-uuid/xxxxxxx-xxxx-xxx-xxxx-xxxxxx

get_dev () {
    if test -b $dev_schwarz; then
	echo $dev_schwarz
	return 0
    elif test -b $dev_silber; then
	echo $dev_silber
	return 0
    else
	return 1
    fi
}

$ cat /usr/local/bin/umount-exthdd
#!/bin/bash

source getbkpdev
timeout=10 # seconds to wait for the device powering off

umount /mnt/exthdd && cryptsetup luksClose /dev/mapper/exthdd_crypt

if [ $? -eq 0 ] && get_dev > /dev/null; then
  i=0
  until udisksctl power-off -b $(get_dev) || [ $i -eq $timeout ]; do
    sleep 1
    i=$(( i++ ))
  done
fi

Für die inkrementelle Sicherung täglich, wöchentlich, monatlich wird rsnapshot verwendet. BorgBackup wird nicht verwendet weil es nicht in Dateien, sondern in ein eigenes Container Format sichert. Allerdings ist für mich die Einfachheit, Solidität und direkter, langlebiger, zukunftssicherer Dateizugriff eine zentrales Kriterium eines Backups. Die Deduplizierung auf Byteebene die BorgBackup im Gegensatz zu rsnapshot bietet, ist bei unseren Daten nicht entscheidend relevant. Darüberhinaus bin ich der Meinung, dass die Deduplizierung eine separate Aufgabe des Dateisystems oder einer dedizierten Schicht zwischen Dateisystem und Anwendung ist. Leider sind die Programme dazu (btrfs, zfs etc.) für GNU/Linux nicht vorhanden bzw. noch nicht ausgereift.

Für rdiff-backup gilt Ähnliches (zumindest für die Inkrements), darüber hinaus scheint es derzeit nicht wirklich aktiv gepflegt/genutzt zu werden. rsnapshot ist im Aufbau recht einfach und setzt über Jahrzehnte bewährte, simple Unix Hausmittel wie Hardlinks, cp, rsync, mv, touch etc. ein.

Für die Auslösung, Steuerung und Überwachung der Sicherung werden cron, anacron und selbst erstellte Bash Skripte verwendet. Systemd wird abseits des Debian Standards nicht verwendet, da die Architektur nicht der Unix Philosophie entspricht.

Server die dauernd eingeschaltet sind und Endgeräte die nur sporadisch im Netz verfügbar sind benötigen eine separate Konfiguration: