Hmm... komisch, ich dachte ein Upgrade inkl. Downsizing-Option von 250 auf 20 würde 1.700,- kosten. Kann mich aber täuschen, bin in der Thematik als reiner Integrator und Software-Produzent nicht so drin.
Ja, das hörte man öfter...
Ein MacPro mit 2 GBit-Interfaces, passendes Routing und Du solltest in dem Setup keinen Unterschied zu einer direkten Verbindung beider Server per GBit-Ethernet spüren. Wichtig ist, daß man "-z" bei rsync ausläßt in so einer Situation (die Komprimiererei bremst mehr als daß sie nützt -- zumindest meine Erfahrung in Gbit-LAN-Situationen). Oder anders ausgedrückt: Vorher bisserl testen. Und bei richtig grottiger Performance sofort
auf dem Mac ausführen, Reboot machen und nochmal probieren.
Mir scheint, Du hast den inkrementellen Sync-Ansatz noch nicht ganz verinnerlicht. Du stellst beide Server parallel auf, läßt dann stur initial den Sync laufen -- evtl. sogar mit gesetzter Option "--bwlimit=KBPS" (limit I/O bandwidth; KBytes per second) damit die in der Produktion auch noch arbeiten können.
Dann kommt der Tag X und Du läßt noch einmal rsync mit identischen Parametern laufen. Dieses Nachsyncen wird deutlich schneller laufen als der initiale Sync, weil nun nur noch die Änderungen gesynct werden.
Da ich grad erlebt habe, wie ein sehr großes Systemhaus mit schwachsinnigen rsync-Parametern eine Server-Migration beinahe erfolgreich sabotiert hätte, noch schnell sinnige rsync-Parameter anbei (immer identische Parameter für initialen und Folge-Syncs nehmen):
(Unter MacOS X natürlich "-E" nicht vergessen)
Migration vierer Suns auf eine neue dicke. Initialer Sync mehrere Tage, danach nächtlich inkrementeller Sync. Letzter inkrementeller Sync am Tag X im Bereich von ein paar Stunden. Und da geht's um TBytes im zweistelligen Bereich und AFAIR mehr als 300 User, die da jeden Tag auf den Server-Volumes herumwurschteln.
Datum