Skip to content
Docs
strackt.io Open app

When moving a service to another server fails

What it means when moving a database or cache to a different server doesn't complete, and how to recover without losing data.

When moving a service to another server fails

You can move a service — a database or cache — from one server to another without rebuilding it by hand. strackt sets up the service on the new server, copies its data across, and keeps the original serving the whole time, right up until you confirm the switch. Because of that, a move that runs into trouble is safe: your service keeps running where it is, and no data is lost while things are sorted out.

A move can report a problem at two points: while it's preparing (setting up the new server and copying data), or at the switch-over itself. Either way, the service page shows what stopped and gives you the controls to recover.

What a failed move means

  • Before the switch-over: the original service is still live and serving. The copy on the new server is half-prepared, but nothing depends on it yet — your applications are still talking to the original.
  • At or after the switch-over: strackt did a final sync before pointing anything at the new server, so your data is intact. If the switch didn't complete cleanly, the safe move is to return to the original.

In both cases the current state is recoverable — the point of the design is that you're never stranded between two servers.

What to do

  1. Read the message on the service page. It tells you where the move stopped. That usually points at the cause — most often the target server being offline, short on disk, or busy with another operation.
  2. Check the target server. A move needs the destination connected, online, and with enough room for the service's data. Bring it back to healthy before trying anything else.
  3. Retry the move. If the cause was transient — a brief blip while data was copying — Retry picks up from where it stopped rather than starting over.
  4. Roll back to the original if you'd rather not continue. If the move has gone far enough that it reports as failed, Roll back returns the service to its original server and reconnects your applications to it. This is the safe way out when a move won't finish.
  5. Abort if you're still early. Before the switch-over, Abort cleans up the half-prepared destination and leaves the original completely untouched — use this if you simply want to call it off.

Before you try again

A move goes more smoothly when the destination is ready: the target server connected and online, with enough disk and memory for the service, and not already running the same service. Clearing those first avoids most repeat failures.

If a move keeps failing while both servers look healthy, reach out — moving a live service is exactly the kind of thing we'd rather work through with you than have you keep retrying.

Was this helpful?