Quickest way to migrate data from one ZimaOS box to another ZimaOS box

Is to use USB drive to copy data to and from.

For last couple of hours trying to move around 600Gb od data from my i7 16Gb memory custom Zima box (ver 1.5.3) to my converted Terramaster (ZimaOS 1.5.4) and after a second or couple of minutes (randomly) stops and display info that host is down. Of course source box isn’t down as I have main page open on separate tab to monitor network speeds (other issue on my 1Gb home network max speed is around 40Mb/s). Refreshing tab with Files app allows for another and another and then another try.

I’ve tried to copy from source to destination and then from destination box copy data from source with the same results. My network is quite small with only two Ethernet devices.

It is just disappointing.

Don’t use the Files app for large migrations, it’s the bottleneck and the reason you’re seeing “host is down”.

What you’re hitting isn’t your network going down. It’s the Files web UI timing out / resetting the transfer. This is a known weakness with long-running, large copy jobs.

Fast, reliable options that actually work:

  1. rsync over SSH (best)
  • Stable, resumable, no UI timeouts
  • Uses the full link if disks can keep up

On destination box:

rsync -avh --progress --partial --inplace \
  user@SOURCE_IP:/DATA/ /DATA/

If it drops, rerun the same command — it resumes.

  1. SMB + a proper client
  • Mount the source share on the destination
  • Copy locally on the destination (not via browser)
  • Much more stable than Files app
  1. USB / NVMe shuttle
  • Still the fastest if you have a spare SSD/NVMe
  • Zero network variables, zero UI issues

What not to do:

  • Don’t use Files app for hundreds of GB
  • Don’t copy box > box via browser tabs
  • Don’t judge network speed from the Files UI (it’s misleading)

Your ~40 MB/s on 1GbE is already a hint the transfer path is inefficient. rsync or a local copy will be both faster and boringly reliable.

If you want, post:

  • source filesystem (btrfs/ext4)
  • destination filesystem
  • disk type (HDD/SSD/NVMe)

Then we can squeeze more speed out of it without guesswork.

Thanks for reply, it gives a lot of information.

But regardless….

I’ve used before a two bay Netgear with DSM (Synology) installed and I’ve moved data between two systems and also from and to Windows host and never had issues like that.

The data I was migrating now was on my old NAS (Netgear) and I copied it all at once without any issues. Mounted smb shares from NAS to Zima and started migration - after a while all was done.

My points is that there is a file app and it allows to mount smb and other shares and it SHOULD work.

End user shouldn’t be forced to resort to using Linux to do something simple task like copy data?!
I’ve look for some app similar to rsync but failed.

Drives on one of my Zima’s are 3TB WD Red Plus HDD’s (5400 rpm) and three 2TB WD (7200) ← source.

Destination have two 2TB Sandisk/WD SSD. File system is ext4 on all.

Regards

Tom

I would like to use tool like MC under shell but unfortunately there is no screen app to keep it in background.

Tom, to better understand what’s happening during the drop, could you please run the following right after the transfer stops and post the outputs?

On the Terramaster (destination):

uptime
free -m
dmesg -T | tail -n 50
docker ps
docker logs files 2>&1 | tail -n 50

On the source box:

uptime
dmesg -T | tail -n 50

And on either box:

ethtool eth0 | grep -i speed

This will help us see whether the system is under memory pressure, if there are disk or network resets, or if the Files container is restarting when the transfer drops. Once we have that, we can narrow it down properly.

Too late. I managed to move all the data yesterday.