A real-world production migration from DigitalOcean to Hetzner dedicated, handling 248 GB of MySQL data across 30 databases, 34 Nginx sites, GitLab EE, Neo4j, and live mobile app traffic — with zero downtime.
Once the dump was complete, we transferred it to the new server using rsync over SSH. With 248 GB of compressed chunks, this was significantly faster than any other transfer method:
that’s a bit weird. rsync -z is compression, but they did compress in the mydumper export already, so this is a slow down (or neutral at best). also in my experience rsync is as fast as scp is as fast as piping anything to the tcp port on the destination etc. rsync does not win for speed but for enabling resume so to say…
As you say other solutions may be just as well or marginally better, but this is an all around good approach that even when pointless doesn’t hurt anything.
rsync -avz --progress /root/mydumper_backup/ root@NEW_SERVER:/root/mydumper_backup/that’s a bit weird. rsync -z is compression, but they did compress in the mydumper export already, so this is a slow down (or neutral at best). also in my experience rsync is as fast as scp is as fast as piping anything to the tcp port on the destination etc. rsync does not win for speed but for enabling resume so to say…
besides this: nice read!
It’s probably just a knee jerk inclusion.
As you say other solutions may be just as well or marginally better, but this is an all around good approach that even when pointless doesn’t hurt anything.