Backup Volume über Netzwerk

dMopp

Banned
Registriert
März 2007
Beiträge
9.688
Hi, ich bin gerade dabei, mein Heimnetzwerk von Overhead zu befreien und Dienste zu optimieren oder gar zu ersetzten.


Gerade bin ich beim Thema Backup.

Daheim werkeln 2 MBPro und 1 iMac. Zusätzlich habe ich nen kleinen Linuxserver mit mdadm raid5 für "wichtige Daten" wie zB Backups.

Folgendes Backupschema wird momentan verwendet:

Automatische TimeMachine backups über AFP (netatalk) direkt auf den Raid5.

Meine Idee:
Für BackUps iSCSI verwenden, da der Overhead geringer ist und die Performance entsprechend höher. Dazu wollte ich pro PC ein image auf dem Server erstellen und das dann als target für den jeweiligen Client freigeben.

Mein "Problem":
Der Server läuft keine 24/7. Ich schicke den Server oft in den Suspend Modus, da er nicht regelmäßig laufen muss. (Mit den 5 Platten verbraucht er trotz e350 dan einfach zu viel für 24/7). Bei iSCSI ist das aber suboptimal, da ich nicht mal weis, ob ich einfach suspenden kann, wenn ein client noch nen mount offen hat und wie sich das mit Datenverlust verhält (bei AFP sollte es theoretisch keinen geben, praktisch leider ebenfalls).

Aktuell verwende ich den ATTO iSCSI initiator (extrahiert aus einem treiberpaket für ein NAS.. CLI only aber prinzipiell am funktionieren)


tl;dr abschließend meine Fragen zusammengefasst:
- Datenverlust Risiko iSCSI vs AFPd
- SUSPEND des Servers bei iSCSI
- Automount von iSCCI devices auf den Clients (insbesondere nach suspend.. einfach nen cron einrichten? Alle 2 Minuten mounten, sofern mount nicht vorhanden?)

ggf bessere Ideen?

(ServerOS Debian 7 mit selbstcompilierten netatalk 3.1.x)
 
iSCSI lohnt sich erst bei 10GBit Ethernet wirklich.
Vorher kommst du mit WLAN in eine Sättigung, bei Nutzung von 1GBit Ethernet bist du ca. an der Grenze, was SATA Platten (ohne 3G) schreiben können.

Kommt also drauf an, wenn du 10Gb und Sata-3g oder SAS-platten hast, könnte sich ein Umstieg evtl. in der Performance lohnen.


Bei AFP kannst du per lsof oder z.B iotop bestimmen (je nachdem wie Apple den Netzwerkzugriff auf Dateien geregelt hat) ob noch ein Backup im Gange ist und per Skript den Suspend verzögern.


Wenn du wirklich ernsthaft Performance-Probleme hast würde ich erst ein mal das Bottleneck suchen.
Falls nicht, empfehle ich dir eine Spielerei, die kaum bis keinen Nutzen bringt, an Backups zu vermeiden.

Auf deine Fragen direkt habe ich leider auch keine Antwort.
 
Ich habe mal Performancevergleiche gemacht. Sequenziell gibts kaum Unterschied, jedoch bei vielen kleinen files. Da ist iSCSI doch deutlich performanter. Die Ursache für die "hohe" CPU-Last habe ich soweit gefunden, das lag an Spotlight bzw Tracker. Komme so auf 60-70% iowait, will heißen 20-30% performance wären theoretisch machbar. mMn aber nicht mehr mit der CPU (E350), die ist bei Spotlight/Tracker völlig am Ende.

Ich bleibe soweit bei AFPd und versuche hier mittels IPv6 und/oder Jumboframes (IPv4) etwas aus zu helfen :D
 
Zurück
Oben