KategorieOpenmediavault

tar auf einen remote Server per ssh

Wie kann man per tar direkt auf einen remote Server schreiben? Warum möchte man direkt per tar auf einen remote Server sichern? Diese Fragestellung tritt speziell dann auf, wenn man auf den zu sichernden Server nur wenig verbleibende Disk-Kapazität hat. Typischerweise sind das dann Datenbankserver, oder wie in meinem Fall Webserver, die eine OwnCloud Instanz hosten. Da auch im Web der Festplattenspeicher teuer ist, nutze ich mein NAS zu Hause zu die Daten zu sichern. Hier steht ja in gewissem Maße unbegrenzter Speicherplatz zur Verfügung.

Also gut, dann erzeugen wir ein Archiv und pipen die Ausgabe direkt per SSH auf den Remote Speicher um.

tar zcvf - /var/www/ | ssh -p 22 root@nas.tschoerner.eu "cat > /media/backup/WebServer.tar.gz"

Nun wird das erzeugte Archiv direkt auf den SSH Server umgeleitet.

Müsst Ihr nun ein Backup wieder herstellen, so könnt Ihr das auch, ohne das Archiv kopieren zu müssen:

cd /
ssh -p 22 root@nas.tschoerner.eu "cat /media/backup/WebServer.tar.gz" | tar zxvf -

 

OpenMediaVault/Debian Wheezy Kernel 4.6 ready to download

Heute habe ich die Zeit genutzt und den 4.6er Kernel für Debian Wheezy, respektive für OpenMediaVault kompiliert.

Bei dieser Version sind die USB Module fest im Kernel, somit könnt Ihr ohne Probleme von einem USB-Stick booten. Zusätzlich habe ich die e1000 Module in den Kernel kompiliert.

Hier könnt Ihr die Kernel herunterladen.

Installieren könnt Ihr die Kernel wie immer mit:

dpkg -i linux*.deb

Viel Spaß damit ….

Debian/Ubuntu bootet nicht, da das Root Device nicht gefunden werden kann

Hallo,

häufig habe ich gesehen, dass User nach dem Kompilieren eines eigenen Kernels auf das Problem stoßen, dass das System nicht mehr bootet. Im speziellen tritt das Problem bei User auf, bei denen das Root device nicht auf einem SATA,SCSI oder SAS befindet, oder aber der Chipsatz spezielle Treiber braucht. So auch bei mir.

Mein Server bootet von einem USB3 Stick, so dass beim Booten schon das XHCI Modul verfügbar sein muss. Ein typischer Indikator ist die Meldung:

Dropping to shell!
modprobe: module ehci-orion not found in modules.dep

2016-03-04 13_18_41-Photo Station 6

Hierzu einfach beim Kompilieren die USB Module, oder aber Chipsatz-Module in den Kernel mit aufnehmen. Beim aus führen von make menuconfig einfach die benötigten Treiber mitkompilieren (als Beispiel USB Block Treiber).

Device Drivers –> USB Support

2016-04-10 11_40_0 2016-04-10 11_40_50 2016-04-10 11_41_15

 

OpenmediaVault, J1900 und der Kernel 4.4

Nach vielen Problemen mit dem 3.16 er Debian Backport Kernel, hatte ich mich im Dezember 2015 dazu entschieden mein NAS auf den 4.x Kernel zu heben. Die war jetzt doch ein längerer Prozess, da es mir einfach nicht gelingen wollte einen Kernel zu bauen welcher von USB bootet.

Es gibt zwar einige Anleitungen wie man den Kernel baut, im speziellen auch für OpenMediaVault, doch leider beinhalten diese keinen USB ohci Treiber. Das System bleibt dann mit folgendem Fehler beim Booten hängen:

modprobe: module ehci-orion not found in modules.dep

2016-03-04 13_18_41-Photo Station 6

Das Problem liegt darin, dass das System das Root-Device nicht findet. Ich boote mein NAS von einem USB Stick am USB3 Port. Nachdem ich nun die USB Storage Module fest im Kernel mit-kompiliere bootet das System auch wieder.

Gerne Stelle ich Euch noch meine „Kernel“ für OMV zur Verfügung!

linux-image-4.4.1-amd64_06+custom+fts_amd64.deb

linux-headers-4.4.1-amd64_06+custom+fts_amd64.deb

Installiert werden diese dann mittels des Befehls:

dpkg -i linux-image-4.4.1-amd64_06+custom+fts_amd64.deb linux-headers-4.4.1-amd64_06+custom+fts_amd64.deb

Hier noch ein link zu meinem Kernel-Ordner

Openmediavault Kernel

Bei Kernelversionen > 3.10 (Version 3) und Kernel Versionen > 4.1.6 musste ich mit dem Argument „intel_idle.max_cstate=1“ arbeiten. Hierbei steigt jedoch die Stromaufnahme an. Das Setting muss in „/etc/default/grub“ eingepflegt werden oder im Bios.

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

ersetzen mit:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"

anschließend
update-grub

 

 

Lebensdauer von Flashdrives unter Debian/Raspbian/Openmediavault verbessern

Nachdem ich mittlerweile etliche Flashdrives, SSDS & SD-Karten in meinen PIs & Server verschlissen habe, dachte ich mir nun, dass es wohl Sinn macht, mich dem Thema mal etwas genauer anzunehmen.

Nach einigen Recherchen im Internet, gibt es grundsätzlich 2 verschiedene Ansätze. Zum einen den, das Haupt OS generell schreibgeschützt aufzusetzen, oder den, verschiedene Verzeichnisse nur in eine Ramdisk zu legen. Ich habe mich für den 2ten Weg entschieden. Und mein OpenMediaVault dementsprechenden gemoddet.

Ich setzte dabei das Paket fs2ram ein. Dieses ist ähnlich der fstab aufgebaut. Im Gegensatz zu einem normal tmpfs mount, können hier Struktur & Daten gesichert werden. Das Paket ist nicht im Standard Repository, und muss manuell geladen und installiert werden.

Für /tmp sollte der Eintrag in /etc/fstab wie folgt schon vorhanden sein, wenn nicht einfach einfügen zudem auch noch das „defaults,noatime“ bei dem Root-Device einrichten:

/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
tmpfs          /tmp           tmpfs      defaults,noatime            0     0

Installation von fs2Ram auf allen Platformen (ARM, X32 & X64)

wget --no-check-certificate "https://miami.tschoerner.eu/deb/all/fs2ram_0.3.12_all.deb" -O fs2ram_0.3.12_all.deb
sudo dpkg -i fs2ram_0.3.12_all.deb

Dies ist meine fs2ram.conf von OpenMediaVault:

#
# In case you want to make /var/lock or /tmp available as ram
# filesystems, it is preferable to set the variables RAMTMP, RAMLOCK
# from /etc/default/tmpfs.
#
#<file system>  <mount point>   <script>                <script option> <type>  <options>
#tmpfs            /var/log        keep_file_content       -               tmpfs
#tmpfs            /var/cache      keep_file_content       -               tmpfs
#tmpfs            /var/tmp        keep_file_content       -               tmpfs
tmpfs            /var/log        keep_file_content       -               tmpfs
tmpfs            /var/cache      keep_file_content       -               tmpfs
tmpfs            /var/tmp        keep_file_content       -               tmpfs
tmpfs           /var/lib/openmediavault/rrd     keep_file_content       -               tmpfs
tmpfs           /var/spool                      keep_file_content       -               tmpfs
tmpfs           /var/lib/rrdcached/             keep_file_content       -               tmpfs
tmpfs           /var/lib/monit                  keep_file_content       -               tmpfs
tmpfs           /var/lib/php5                   keep_folder_structure   -               tmpfs

Nach den Änderungen sollte man das System einmal durchstarten.

Falls Ihr eine Disk im System als Root-Disk habt, könnt Ihr noch mit „hdparm“ herumspielen.

#aktuelle Disk status
root@London:~# hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  active/idle

#Disk schlafen schicken
root@London:~# hdparm -y /dev/sdc

/dev/sdc:
 issuing standby command

#status prüfen
root@London:~# hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  standby

#Disk nach 5 Minuten automatisch herunterfahren
root@London:~# hdparm -S 60 /dev/sdc

Openmediavault Disk IO on Linux and Windows vBox Guest

Da man ja bekanntlich ;D zwischen den Jahren nicht viel zu tun hat, habe ich heute die Kernel Logs meines NAS auf Basis von OpenMediaVault geprüft. Mir fiel dabei auf, dass der aktuelle Kernel von Wheezy keine optimale Unterstützung für die von mir eingesetzte j1900 CPU (Intel ARK).

Nachdem ich mit einen „Custom“ Kernel genaut habe, passen jetzt auch die non-free treiber zum j1900. Dieser unterstützt jetzt auch im Burst-mode 2.4 Ghz.

root@London:~# cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Bitte melden Sie Fehler an cpufreq@vger.kernel.org.
analysiere CPU 0:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0
  Maximale Dauer eines Taktfrequenzwechsels: 0.97 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 1.33 GHz - 2.42 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 1.33 GHz und 2.42 GHz.
                    liegen. Der Regler "powersave" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.33 GHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 1:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 1
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 1
  Maximale Dauer eines Taktfrequenzwechsels: 0.97 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 1.33 GHz - 2.42 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 1.33 GHz und 2.42 GHz.
                    liegen. Der Regler "powersave" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.33 GHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 2:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 2
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 2
  Maximale Dauer eines Taktfrequenzwechsels: 0.97 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 1.33 GHz - 2.42 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 1.33 GHz und 2.42 GHz.
                    liegen. Der Regler "powersave" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.34 GHz  (verifiziert durch Nachfrage bei der Hardware).
analysiere CPU 3:
  Treiber: intel_pstate
  Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 3
  Die Taktfrequenz folgender CPUs werden per Software koordiniert: 3
  Maximale Dauer eines Taktfrequenzwechsels: 0.97 ms.
  Hardwarebedingte Grenzen der Taktfrequenz: 1.33 GHz - 2.42 GHz
  mögliche Regler: performance, powersave
  momentane Taktik: die Frequenz soll innerhalb 1.33 GHz und 2.42 GHz.
                    liegen. Der Regler "powersave" kann frei entscheiden,
                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.
  momentane Taktfrequenz ist 1.35 GHz  (verifiziert durch Nachfrage bei der Hardware).
root@London:~#

Wenn jetzt also die Treiber besser passen, dachte ich mit, teste ich noch schnell mal den IO auf mein internes RAID5 (3x WD RED). Eine einfache Messung habe ich auf der Konsole mittels dd durchgeführt.

Test 1: 8k Länge & Anzahl 256k

Test 2: 8K Länge & Anzahl 512k

root@London:/media# dd if=/dev/zero of=/media/3e0a8081-0482-4a84-8e05-ae2106117e16/test/output.img bs=8k count=256k
262144+0 Datensätze ein
262144+0 Datensätze aus
2147483648 Bytes (2,1 GB) kopiert, 7,72799 s, 278 MB/s
root@London:/media# dd if=/dev/zero of=/media/3e0a8081-0482-4a84-8e05-ae2106117e16/test/output.img bs=8k count=512k
524288+0 Datensätze ein
524288+0 Datensätze aus
4294967296 Bytes (4,3 GB) kopiert, 17,2436 s, 249 MB/s

In einem VirtualBox Windows Gast habe ich eine Messung mit Cristal Mark gemacht. Auch hier war ich mit der Leistung durchaus zufrieden.

cristal_mark_LYON_TerminalServer_VM_test2

Als Vergleich noch mein Laptop mit SSD & HDD:

SSD:

SSD_c-Drive

HDD:

HDD_D-Drive

Mit der Disk-Performance meines NAS Server kann ich wohl ganz zufrieden sein.