Denke es wird ziemlich aneinander vorbei geredet.
Beim vorher genannten rsync-Ansatz (und ähnliche Methoden) geht dd nicht. dd kann von sich kein Resume oder Tracking von Änderungen (man kanns basteln, mit LVM Snapshot, Copy-on-Write Overlays, aber... Aufwand).
Beim dd-Ansatz machst du also die gesamte Übertragung in einem Schritt offline und so lange wie das dauert, so lange dauert es dann eben. Wenn dir das lieber bzw. sicherer ist, dann ist das auch vollkommen in Ordnung. Da brauchen wir uns aber auch nicht den Mund fusselig reden zu Downtime und Optimierungsansätzen.
Deine Einwände mit Datenbank-Konsistenz, 2 Instanzen & Co. — das ist klar, diese Probleme hast du bei jeder anderen Anwendung doch auch, nicht nur bei Datenbanken. Aber es ist kein Problem, solange — der Zielserver die ganze Zeit nur im Rescue steht und brav Daten empfängt.
Erst im letzten Schritt geht der Quellserver ins Rescue, stellt die erforderliche Konsistenz her (Übertragung der letzten Änderungen von Rescue zu Rescue), und erst dann startet der Zielserver, mit den übertragenen, konsistenten Daten.
Klappt alles mit rsync ohne Probleme, vorausgesetzt man hat ein Dateisystem mit ordentlichen Timestamps. Und nicht FAT32 mit 2-Sekunden-Taktung. Ohne Timestamps weiß rsync nicht, was nochmal zu kopieren ist und was nicht…
Die Konsistenz spielt erst im letzten Schritt eine Rolle.