Sie sind nicht angemeldet.

Anzeigen

**Wir werden in den kommenden Tagen einen Umzug auf einen neuen Server durchführen. Im Rahmen dieser Maßnahme wird das Forum ca. 1 Stunde nicht erreichbar sein.** nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

Lieber Besucher, herzlich willkommen bei: Die NSLU2 Community****wenns ums speichern und streamen geht****. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

18.11.2007, 17:56

NSLU als Backupserver

Ich habe meine NSLU [1] als Backupserver eingeplant.

Da ich aber nur begrenzt Plattenplatz [2] auf der an der NSLU angeschlossenen Festplatte zur Verfügung habe und ungern auf tägliche Versionsstände verzichten möchte, versuche ich folgenden Lösung:

Sicherung durch ein Backup-Skript [3] auf ein mittels Truecrypt erstelltes virtuelles Laufwerk [4] auf der NSLU. Dieses wird speziell für das Backup gemountet und erscheint solange als lokales Laufwerk in Windows.

Nun zum eigentlichen Problem:
Die NSLU stürzt nach einer unbekannten, variablen Datenmenge (geschätzt ca. 10-15 GB) ab und ist nicht mehr, weder über das Webinterface, FTP oder SMB ansprechbar. Einzig auf Pings reagiert sie noch ganz normal.
Selbst der im Webinterface, auf eine bestimmte Uhrzeit, terminierte Neustart unterbleibt.
Sie ist nur durch eine kurze Stromunterbrechung wieder zur Mitarbeit zu überreden.

Hat jemand eine Idee, warum sich die NSLU daran verschluckt?



[1] V2.3R63-uNSLUng-6.8-beta - Unslung to disk1 (USB-Flash Stick 1GB), /dev/sdb1
[2] 1 x Maxtor OneTouch III 300GB
[3] http://alfafox.info/backup-auf-ntfs-festplatte-mit-rsync.htm
[4] 100GB, Dateisystem: NTFS, verschlüsselt


was hast Du bereits probiert?: Schon das Erstellen/Formatieren der 100GB großen Containerdatei wird durch die begrenzte Übertragungsrate der NSLU zum Geduldsspiel (Zeitdauer mehrere Stunden ca. 4 MB/s).
Deshalb habe ich dazu die Festplatte temporär lokal angeschlossen und mittels [1] in Windows eingebunden.

Die UPnP-Einstellung ändert nichts am eigentlichen Problem.


[a] http://www.fs-driver.org/

Die Suche schon benuzt?: ja

Art der Firmware: V2.3R63-uNSLUng-6.8-beta

wird ein externer Datenträger genutzt, wenn ja, was für eine Art: 1 x Maxtor OneTouch III 300GB
NSLU Firmware: V2.3R63-uNSLUng-6.8-beta
Unslung to disk1, /dev/sdb1
Disk 1: takeMS USB Mini - 1 GB

Disk 2: Maxtor One Touch III - 300 GB - funktionierendes SpinDown nach 15min

Anzeigen

Eiffel

Profi

Beiträge: 619

Beruf: SAP Anwendungsbetreuer

  • Nachricht senden

2

21.11.2007, 09:28

4MB/s sind normal für die Slug viel mehr geht da nicht

ups darum ging es garnicht

meine Vermutung ist das die Slug alle möglichen Dienste killt um noch irgendwie an Speicher ran zukommen
du könntest mal schauen ob der swap space nicht ausreicht

Anzeigen

3

21.11.2007, 20:00

Ja, sowas in der Art hatte ich auch schon vermutet.
Durch die Option Ext3flash [1] wird der SWAP-Space zumindest auf dem Root-Drive deaktiviert.

Aber das SWAP-Space der USB-Disk wird wohl verwendet:
(aktueller Stand, allerdings ohnen größere Dateiaktionen)

Zitat

# free
..............total.....used......free...shared...buffers
Mem:.....30524...29760.......764.........0...12624
Swap:...120480....1652..118828
Total:...151004...31412..119592
Ich hatte nur gehofft, bei anderen wäre auch ein Fehler bei größeren Dateiaktionen aufgefallen, wobei man natürlich tatsächlich nicht gerade jeden Tag mehrere 10 GB transferiert...
Ich habe es jetzt auch nach mehreren Anläufen geschafft. Bei allen weiteren Durchgänge ist die zu übertragende Datenmenge wesentlich geringer, so dass der Fehler vermutlich nicht mehr auftreten sollte.

Ich versuche aber weiterhin der Ursache auf die Spur zu kommen. Ich könnte mir auch vorstellen, dass er hier ebenfalls ein Rolle spielt: http://www.nslu2-info.de/showthread.php?t=6311


Seltsamerweise kann ich weder "procps-top" noch "atop" starten, da beide sinngemäß mit der Meldung

Zitat

TERM environment variable not set.
abbrechen und mir so die Fehlersuche erschweren.


[1] http://www.nslu2-linux.org/wiki/Unslung/Ext3flash
NSLU Firmware: V2.3R63-uNSLUng-6.8-beta
Unslung to disk1, /dev/sdb1
Disk 1: takeMS USB Mini - 1 GB

Disk 2: Maxtor One Touch III - 300 GB - funktionierendes SpinDown nach 15min

innovonet

Schüler

Beiträge: 157

Verwendetes NAS-Device: NSLU2

Firmwareversion / your current Firmware: Unslung 6.10

Wohnort: Giessen

Beruf: Dipl.-Ing.Elektro

  • Nachricht senden

4

22.11.2007, 22:53

Hallo Quick, ein Ursache dürfte die Verwendung von NTFS sein. Es handelt sich dabei um das langsamste Dateisystem und kann auch gelegentlich hängen. Eine andere Ursache ist die Verwendung von Shares. Zum Glück kann rsync blockweise inkrementell kopieren, so dass Du auch bei größeren Backups irgendwann fertig wirst. Aber überprüfe in einem Trockenlauf mit Checksumme, ob wirklich alle Dateien vollständig sind.
Zur internen IO-Performance schau mal in meinen älteren Beitrag: http://nslu2-info.de/showthread.php?t=5571
Zur Netzwerktransferrate schau mal in http://nslu2-info.de/showthread.php?p=24684#post24684

Es gibt noch die Möglichkeit, auf der NSLU2 den Rsync Daemon zu installieren. Die Verwendung der Konfigurationsdateien ist, wenn man sie erst einmal verstanden hat, gar nicht so kompliziert.
Eigenschaften:
- Erspart den zeitweiligen Share und damit
- entlastet wahrscheinlich die NSLU2
- damit weniger Abstürze.
- Möglichkeit der gesicherten Übertragung mit SSH. Vielleicht interessant für Fernzugriff?
- Rsync mit anderen Nslu2 oder anderer lokaler Platte zeitgesteuert per Cron. (lokal geht auch ohne Daemon).
- Sofern der Rsync Daemon die Untersuchung der Zieldateien übernimmt bis zu doppelt so schneller Vergleichslauf.
Ansonsten empfehle ich zwecks Absturzsicherheit und Performance den Umstieg auf Ext3 Dateisystem. Falls die Verschlüsselung unumgänglich ist schau mal, ob es das auch als Nslu2 Paket für Ext gibt.
Gruß, Thomas
V2.3R63-uNSLUng-6.10-beta, WD TV Live, Noxon. Zeitweilig mal Soundbridge, FSG3, Intradisk, Showcenter 200.

5

23.11.2007, 14:36

Zitat von »innovonet;28215«

Ansonsten empfehle ich zwecks Absturzsicherheit und Performance den Umstieg auf Ext3 Dateisystem.

Hallo Thomas, vielen Dank für Deine Antwort.
Als grundlegendes Dateisystem kommt schon EXT2 auf der NSLU zum Einsatz. Nur habe ich darin eine Containerdatei von Truecrypt erstellt und erst diese beinhaltet das Dateisystem NTFS.
Dadurch erscheint das verschlüsselte Volume als lokales Laufwerk auf meinem Computer, im Prinzip ähnlich einem NDAS. Damit wollte ich zum Einen die beschränkten Rechenleistung der NSLU etwas umgehen. Außerdem wäre daneben noch das Problem, dass Truecrypt nativ auf der NSLU (zumindest zur Zeit) wohl auch noch gar nicht so richtig stabil läuft.
Und zum Anderen schien mir dies als der einzigste Weg, die NTFS-Spezialitäten (Hardlinks) des Backup-Skripts richtig nutzen zu können.

Ich habe mir als zwingende Voraussetzung gesetzt, dass das Backup-Laufwerk (und damit das NSLU) nicht am selben physichen Platz wie die zu sichernden PCs steht - um bei Feuer, Überschwemmung, Diebstahl, usw. eben möglichst nicht beides gleichzeitig zu verlieren.
Der Ansatz mit der Containerdatei kam daher, dass die Backupdatei ursprünglich verschlüsselt (und somit auch vor Fremdzugriff [Auslesen, Viren, usw] gesichert) bei einem Bekannten (mehrere 100 mtr entfernt) installiert sein sollte und das Ganze dann per WLAN-Richtfunkverbindung angebunden ist.

Dein Vorschlag Rsync nativ auf der NSLU zu benutzen wäre zwar grundsätzlich denkbar, erfüllt aber nicht meine Anforderungen an Integrität und Zugriffsschutz der Daten.
Die Containerdatei war nicht ausschließlich nur für die NSLU gedacht, sondern zukünftig für jedes beliebige eingesetzte (und vielleicht auch fremdadministrierte) NAS-System (insbesondere eines mit mehr Datendurchsatz), also im Prinzip der Gegenseitigkeit: mein Bekannter bekommt 100 GB auf meinem NAS und ich entsprechend auf seinem.

Aber es freut mich sehr, hier weitere Ideen sammeln zu können, um alles weiter reifen lassen zu können.

Zum eigentlichen Problem werde ich demnächst bei einem Backuplauf mal den Speicher der NSLU mittels "free" etwas überwachen, in wie weit er sich tatsächlich füllt und ausgehen könnte.
NSLU Firmware: V2.3R63-uNSLUng-6.8-beta
Unslung to disk1, /dev/sdb1
Disk 1: takeMS USB Mini - 1 GB

Disk 2: Maxtor One Touch III - 300 GB - funktionierendes SpinDown nach 15min

Social Bookmarks