Transferraten mit USB, SATA, LAN und intern

Dies ist ein historischer Artikel von ca. 2010.

Wer sich mit dem Gedanken trägt, Backups auf einem externen Gerät durchzuführen, hat die Wahl zwischen externen  Platten, die mittels USB, LAN oder SATA angebunden werden können. Hierfür existieren spezielle Leergehäuse. Die LAN-Gehäuse kosten dabei deutlich mehr als die anderen Varianten. Alternativ ist auch die Nutzung eines zweiten Mini-PCs via LAN  möglich, den man im Internet günstig ersteigern kann.

Im folgenden sind unterschiedliche Szenarien gegenübergestellt, bei denen Dateien kopiert werden und die Transferraten gemessen wurden. Mit externen SATA-Platten wurde keine Messung gemacht mangels SATA-Gehäuse.

Ergebnis

Während beim internen Kopieren (also von Harddisk zu Harddisk innerhalb eines Rechners) fast 60 MByte/s erreicht werden, fallen alle anderen Technologien deutlich ab.

Die als externe Harddisk angeschlossene 2,5“ USB-Disk kommt mit 8,7MByte/s nur auf einen Bruchteil (knapp 10%) der theoretisch möglichen 60MByte/s (entspricht 480MBit/s). Da ist sogar die extern gemountete LAN-Platte des Mini-PCs schneller, die mit 10,5MByte/s immerhin 84% der theoretisch möglichen 12,5MByte/s (entspricht 100MBit/s) erreicht. Eine externe, LAN-fähige Platte kommt da auch nicht mit und erreicht sogar nur 3.5MByte/s. Diese Platten werden z.B. von Longshine angeboten und beinhalten einen Microcontroller, auf dem ein proprietäres Betriebssystem oder auch Linux (bei Longshine) läuft. Durch die niedrige Taktrate des Controllers ist für die Transferrate wohl mehr als der Wert, den ich in Foren im Internet gefunden habe, nicht drin.

Nachtrag 2007: Mit einer externen, über USB angeschlossenen 3,5“ Harddisk wurden deutlich höhere Werte als mit der 2,5“ Notebookplatte erreicht. Die verwendete 3,5“ Platte war ein 20GByte Seagate Baracuda Modell aus 2001, ATA4-fähig, also nicht ganz neu und von daher eher langsam. Dennoch wurden 28MByte/s Transferrate erreicht. Die früher getestete Notebookplatte fällt daher mit ihren 8,7MByte/s vermutlich aus dem Rahmen, sie ist besonders langsam. Dies ist vermutlich dem gewünschten niedrigen Stromverbrauch und der möglichst geringen Lautstärke von Notebookplatten geschuldet.

Ich habe in 2007 mein LAN auf Gigabit umgestellt und auch Messungen gemacht. Dies habe ich hier beschrieben.

Nachtrag 2008: Auf einer etwas neueren Plattform habe ich 2008 Messungen mit einer externen, über E-SATA angeschlossenen Harddisk gemacht. SATA bietet die Möglichkeit, neben internen Platten auch externe anzuschließen. Dafür gibt es spezielle, abgeschirmte Kabel, bei denen Längen bis ~2m möglich sind. Ich habe ein externes Gehäuse gekauft, dass 2 SATA.-Platten aufnimmt. Das Fantec MR-35DUS2 hat einen eigenen internen SATA-Controller. Dieser kann eine oder zwei eingesteckte, schnell und ohne Schrauben wechselbare Platten verwalten. Er kann die Platten in verschiedenen Modi betreiben ( RAID0, RAID1, BIG, JBOD).

Das Fantec MR-35DUS2 für 2 SATA-Platten mit E-SATA und USB Anschluss

Ich habe nur eine Platte eingesteckt und gemessen. Es sind im Schnitt über 60MByte/s möglich. Damit ist E-SATA bei meinen Tests der klare Sieger und genauso schnell wie interne Platten. Ein einem anderen Bericht im Internet habe ich gelesen, dass jemand mit zwei Platten in RAID0 sogar 110 MByte/s erreicht hat.

Fazit

Somit erscheint die Variante mit einem externen E-Sata Laufwerk optimal. Als zweitbeste Lösung erscheint ein Mini-PC. Mini-PCs gibt es z.B. von Siemens (Scovery) oder von HP. Der Mini-PC lässt sich problemlos mit einer leichtgewichtigen Linux-Distribution (z.B. Zenwalk) bestücken.
Mit Gigabit-Ethernet wird die LAN-Variante weiter an Attraktivität gewinnen. Der begrenzende Faktor bei Gigabit-Ethernet wird dann wieder die Platte selbst sein, so dass Transferraten wie intern möglich sein sollten.
Externe Harddisks sind dann vorzuziehen, wenn Mobilität gefragt ist.

Medium Quelle Medium Ziel Verbindungstechnik Volumen
[MByte]
Übertragungs-
dauer [s]
Transferrate
[MByte/s]
interne HD
UDMA 133
Linux reiserfs3
interne HD
SATA-1
Linux reiserfs3
intern (SATA/IDE) 1079 18,9 57
interne HD
UDMA 133
Linux reiserfs3
externe HD 3,5“
DOS FAT32
USB2 (Externes Festplattengehäuse: Power Mobile Harddisk. Chip: Cypress Semiconductor Corp. USB-2.0 IDE Adapter) 2045 73 28
interne HD
UDMA 133
Linux reiserfs3
externe HD 2,5“
DOS FAT32
mount mit „async“
USB2 (Externes Festplattengehäuse: No Name. Chip: Genesys Logic, Inc. USB 2.0 IDE Adapter) 1950 223 8,7
interne HD
UDMA 133
Linux reiserfs3
externe HD via NFS
Linux reiserfs 4
mount mit „sync“
Fast Ethernet 100MBit/s 1079 308 3,5
interne HD
UDMA 133
Linux reiserfs3
externe HD via NFS
Linux reiserfs 4
mount mit „async“
Fast Ethernet 100MBit/s 1079 103 10,5
interne HD externe LAN-fähige
Harddisk
Longshine
Linux ext3
Fast Ethernet 100MBit/s unbekannt unbekannt 3,5
(Wert aus Internet)

Getestet wurde mit folgenden Geräten:
Quellrechner:
CPU: Intel Pentium 4 3.0 Ghz, RAM: 1024 MB PC400 DDR, Board: ASRock P4V88 (SATA RAID 8xUSB). Betriebssystem: OpenSuse 10.0.
Zielrechner:
CPU: Intel Celeron 900Mhz, RAM: 512MB PC133 SDRAM, Board: Siemens Scovery XS D1215. Betriebssystem: Zenwalk Linux 2.0.1.

 

Medium Quelle Medium Ziel Verbindungstechnik Volumen
[MByte]
Übertragungs-
dauer [s]
Transferrate
[MByte/s]
interne HD
SATA-II
Linux OpenSuse 11.0
ext3
externe HD
SATA-II
ext3
E-SATA verschiedene Dateien von 0,2-2,8GB unterschiedlich 60,5 im Schnitt (45..77)

Getestet wurde mit folgenden Geräten:
Quellrechner:
CPU:Intel Quad Core 2,4GHz, RAM: 2048 MB PC400 DDR. Betriebssystem: OpenSuse 11.0.

 

VirtualBox unter OpenSuse 11.x

Dies ist ein historischer Artikel von 2010.

Von VMWare zu VirtualBox…

VMWare läuft gut unter Linux. Es ist schnell und bindet sich gut in die vorhandene Hardware ein. Ich konnte sogar auf die vorhandenen seriellen Schnittstellen zugreifen.

Nachteil von VMWare war aber immer, das die VMWare Server Version, die bei VMWare herunterzuladen ist, meist nicht zum vorhandenen OpenSuse Kernel passt. Der Kernel ist meist „zu neu“ für VMWare. Dies hat den Effekt, dass VMWare bei der Installation, die manuell erfolgen muss, Kernel Module neu compilieren muss. Die kann man mal machen, ist eigentlich nicht so schlimm.

Leider muss diese Prozedur immer wiederholt werden, wenn beim einem Systemupdate eine neue Kernelversion mitkommt. Dies führt dazu, dass ich alle paar Wochen die manuelle Installationsprozedur von VMWare Server starten musste. Am Ende muss dann auch immer noch der (kostenlose) Lizenzkey eingegeben werden, alles in allem eine nervige und aufwendige Prozedur.

In den letzten drei Jahren kam es leider auch mehrfach vor, dass VMWare eine Zeitlang gar nicht installierbar war, weil es bei der Nachcompilierung zu Fehlern kommt und die Kernelmodule nicht erstellt werden können. Es gibt dazu die inoffiziellen(?) „any-to-any“-Patches, die VM-Ware für neuere Kernel-Versionen fit machen. Das Beschaffen der Patches und das Checken, ob sie für Kernel+VMWare Version ordentlich passen, ist dann immer eine Bastelarbeit.

Installation

Im Frühjahr 2010 trat die Situation wieder auf, ich konnte die neueste VMware Version nicht auf meinem OpenSuse 11.2 installieren.

Diesmal habe ich VirtualBox eine Chance gegeben.

Vor einiger Zeit hatte ich das schon mal probiert, aber damals musste man die Netzwerk-Konfiguration des Host-Rechners verändern, um unter dem Gast Networking verwenden zu können, was ich damals nicht tun wollte.

Dies ist in der aktuellen Version 3.2.6 vom VirtualBox nicht nötig. Unter OpenSuse kann einfach via YasT nachinstalliert werden. Nach der Installation hat man eine Verwaltungsfenster, in dem die Virtuellen Maschinen sichtbar sind und von dort aus gestartet, gestoppt und verändert werden können.

Import vorhandener VMware VMs

Vorhandene VMWare-VMs können tatsächlich importiert werden. Das Import-Format ist OVF, soweit ich verstanden habe eine Art Standard, um eine VM strukturiert zu verpacken. Es gibt von VMWare einen Skript, OVFTOOL, den man sich bei vmware herunterladen kann. Nach Start des heruntergeladenen sh-Skripts entpackt sich das Tool und installiert sich in ein wählbares Verzeichnis. Eine vorhandene VMWare-VM kann dann mittels ovftool /dir-der-vorhandenen-vmware zieldatei in das Standardformat konvertiert werden.

VirtualBox bietet einen Punkt „Importieren“ an, der das Importieren der VM im Standardformat erlaubt. Ich habe dies für eine VM gemacht und es hat gut funktioniert.

Nutzung

Das Handling ist genauso bequem wie mit VMWare Server. In untigem Bild wird gerade OpenSuse 11.3 64 Bit installiert.

Gast Erweiterungen

<noch offen>

Stabilität

Mit meinen beiden ersten VMs (Windows XP Professional) habe ich keine Abstürze oder anderen unangenehmen Effekte gehabt. Das ganze wirkt sehr stabil.

Konvertierung von VirtualBox VMs nach VMware VDMK

Warum braucht man das? Ich arbeite zuhause mit virtualbox, muß aber bei meinem Arbeitgeber VMware nutzen. Daher brauche ich auch den Weg von Virtualbox VM (im .vdi-Format) zum .vmdk-Format oder irgenbdwas anderem, was VMware versteht.
Laut Internet Foren soll das mittel VBoxManage. Beispiellink:
http://communities.vmware.com/thread/197423

VBoxManage clonehd          <uuid>|<filename> <outputfile>
[–format VDI|VMDK|VHD|RAW|<other>]
[–variant Standard,Fixed,Split2G,Stream,ESX]
[–type normal|writethrough|immutable]
[–remember] [–existing]

Evtl. auch
VBoxManage export           <machines> –output|-o <ovf>
[–legacy09]
[–vsys <number of virtual system>]
[–product <product name>]
[–producturl <product url>]
[–vendor <vendor name>]
[–vendorurl <vendor url>]
[–version <version info>]
[–eula <license text>]
[–eulafile <filename>]

<noch auszuprobieren>

Fazit

VirtualBox ist mittlerweile ausgereift und kann ganz simpel installiert werden. Es sind keine Nacharbeiten nötig. Es ist besser in das Linux-Restsystem integriert als VMWare Server, insbesondere treten beim Wechsel des Kernels nicht die VMware-üblichen Probleme auf. Ich habe nach einiger Zeit die Reste von VMware aus meinen Linux-Installationen entfernt.