1. USB unterstützt mehrere Übertragungsmodi, unter anderen auch einen der für große Datenmengen eine nur sehr geringe CPU-Last verursacht. Natürlich gibts auch Modi, die für langsame Geräte (und ich meine nicht die Übertragungsrate!) gedacht sind. Diese kommen aber bei Festplattentransfers nicht zum Einsatz, sondern sind z.B. für Geräte wie Tastatur oder Maus gedacht. Die Aussage, dass Firewire immer schneller ist, ist nicht korrekt, auch wenn es bei bestimmten Übertragungen Vorteile mitbringt (z.B. Videokameras). Für Festplatten nehmen sich USB 2.0 High Speed und Firewire nix, vorausgesetzt man vergleicht ebenbürtige HW-Controller und Treiber-Implementierungen.
2. Das Problem beim Backup ist nicht vordergründig die CPU! Klar würde es mit 'ner schnelleren CPU etwas besser werden, aber Brute Force führt hier nicht zum gewünschten Effekt, da wohl ein algorithmisches Problem zugrunde liegt. Sonst würden die Atom-basierten NAS gigantisch viel schneller auf NTFS schreiben, tun sie aber nicht. Auch auf einem GHz-Desktop ist es grottenlangsam. Hauptursache ist der bescheidene NTFS-Dateisystemtreiber. NTFS ist von der Architektur zwar etwas komplizierter aufgebaut als ext2/3 (hat u.a. mehr Features wie Verschlüsselung und Kompression integriert), aber das erklärt nicht diese unverhältnismässig schlechte Performance, da diese Features ja gar nicht verwendet werden! Ist tippe mal ins Blaue ;): Kein Linux-Entwickler wird Interesse daran haben, ein Nicht-Open-Source-Dateisystem so perfekt zu unterstützen wie ein Natives und erst recht keines von MS ;). Man kann am Patentwahnsinn hinsichtlich FAT16 sehen, warum das so ist. Niemand steht gern mit einem Bein im Kittchen. Außerdem sind nicht alle technischen Spezifikationen öffentlich verfügbar und somit ist eine effiziente Umsetzung aller Features von NTFS schwer bis kaum möglich. Das es auch schneller geht beweisen Firmen wie Paragon, die sicher per NDA Zugriff auf die NTFS-Spezifikation haben (und sicher auch ordentlich dafür an MS gelöhnt haben 
).
Aber zurück zu Thema. Der einzige Weg, um die Backups bei großen Datenmengen mit vernünftiger Geschwindigkeit hinzubekommen, ist die Verwendung eines nativen Linux-Dateisystems. Und das NAS unterstützt so wie es ist nunmal nur ext3. Das ist für einen reinen Windows-Benutzer sicher nicht schön, andererseits könnte es schlimmer sein. Denn immerhin gibts dafür sogar 2 Windows-Treiber, wohingegen für das bei anderen NAS verwendete XFS-Dateisystem gar keiner existiert und man grundsätzlich auf ein Linux-Live-System angewiesen ist.
Also ich mache mein Backup lieber auf ein perfekt unterstütztes und jahrelang erprobtes natives Dateisystem (hier ext3) als ein unvollständig implementiertes und halbherzig gepflegtes. Ich bin selber SW-Entwickler und schon aus diesem Grund eher skeptisch hinsichtlich vorhandener Bugs im NTFS-Treiber. Eine quälend langsame SW lässt häufig auf strukturelle Probleme der Implementierung schliessen, oft leider mit entsprechenden Folgen. Ihr solltet immer daran denken, so ein Dateisystem ist nicht trivial sondern recht komplex und damit gibts viele Fehlerquellen. Nicht umsonst dauert die Entwicklung seehr lange.
Achja, wichtig ist bei Verwendung eines der Windows ext3-Treibers, nach dem Backup wirklich damit zu prüfen, ob man die Daten damit auch wirklich lesen kann. Da es sich bei den Windows-Treibern um ext2-Treiber handelt (kein Journaling unterstützt), ist es außerdem wichtig, die Backup-Platte immer vorschriftsmäßig abzumelden. Keiner der ext2-Treiber kann sonst auf die Disk zugreifen, da das Dateisystem inkonsistent markiert ist und einem ext2-Treiber die Funktionalität fehlt, das zu beheben. Also die Platte nicht einfach ausschalten oder den USB-Stecker rausreißen! Sonst bleibt dann in letzter Not doch nur eine Linux Live-DVD.
. Fuer solche Aufgaben kopiert man die zu bearbeitende Datei besser auf die lokale Platte und nach der Bearbeitung wieder zurueck.