The source user's problem was not simply “two ZimaOS boxes cannot copy data.” They were moving roughly 600 GB between systems running ZimaOS 1.5.x and the Files transfer repeatedly stopped with a “host is down” message while both servers themselves stayed online.
That historical behavior should be separated from current ZimaOS. IceWhale now explicitly recommends LAN Storage in Files when moving data from another NAS, while the current Backup app can target another Zima device and provides resumable, fault-tolerant jobs. For a very large transfer, choose the method based on whether you want a one-time visible copy, a resumable protection task, or the fastest physical shuttle.
The Source Files Transfer Repeatedly Reset While Both Hosts Stayed Online
The user tried both directions: pushing from the old ZimaOS box and pulling from the new one. In both cases the browser-based Files workflow eventually stopped, even though the source dashboard remained reachable.
The Community Recommended rsync as the Most Resumable CLI Option
A community reply proposed rsync over SSH with partial-transfer support so an interrupted copy could be rerun without starting over. That is useful advanced guidance, but it was not posted by IceWhale staff and the source user did not confirm using it.
Current IceWhale Guidance Still Uses Files for NAS-to-NAS Migration
Current ZimaOS documentation recommends adding the old NAS as LAN Storage in Files and copying folders into the new ZimaOS storage. That means the old 1.5.x timeout should not be generalized into “never use Files for large migration.”
Use the current LAN Storage migration workflow for a normal visible copy.
Current Backup Can Target Another Zima Device
For long-running transfers where resume behavior matters more than manually browsing the destination, the current Backup app supports another Zima device as a destination. IceWhale documents schedules, real-time progress, resume, and fault tolerance.
See the current resumable Zima-to-Zima backup workflow.
SMB Is a Straightforward Alternative to Browser Copy Logic
The source community also recommended mounting the source SMB share on the destination and copying from the destination side. The user had previously moved data successfully from an older NAS into ZimaOS using mounted SMB shares.
A USB or NVMe Shuttle Can Be Fastest When the Boxes Are Physically Nearby
For hundreds of gigabytes or multiple terabytes, a fast external SSD/NVMe can avoid all network variables. The tradeoff is two copy passes: source to shuttle, then shuttle to destination.
Many Small Files Can Make Migration Look Much Slower
AppData, thumbnails, photo sidecars, code trees, and other metadata-heavy datasets can move far slower than large media files because each file needs open/create/metadata operations.
Verify Before Deleting the Source
After any migration, compare representative folders, file counts where practical, and open critical files on the destination. Keep the source intact until the new box has been used successfully and a backup exists.
Files and Backup Solve Different Migration Problems
Files is the clearer choice when you want to browse the source, choose particular folders, and see the copied files immediately at the destination. Backup is better when the transfer is expected to run for hours or days and you value resume/fault tolerance, scheduling, and a recoverable task history.
Do not call a Backup job a transparent “move.” It creates a protected copy with its own restore semantics; confirm the destination layout before deleting the source.
Check the Network Path Before Optimizing the Copy Tool
On a nominal 1 GbE link, verify that both machines actually negotiated Gigabit Ethernet, that no Wi-Fi or 100 Mb/s segment is involved, and that the switch/cabling are healthy. A copy tool cannot exceed a slow physical link.
Then test one large file. If a large file is fast but a directory tree is slow, the dataset's file count/metadata overhead is likely more important than raw network bandwidth.
User Files and Live AppData Need Different Handling
Movies, photos, and documents can usually be copied as ordinary files. Live application databases and AppData may require the application to be stopped, exported, or migrated with application-aware procedures so the copy is internally consistent.
Do not assume that copying a running database directory between boxes produces a valid application migration.
Preserve or Rebuild Share Permissions Deliberately
Even when every byte arrives, the destination ZimaOS box has its own users, share definitions, and container mappings. Re-create the required Samba permissions and app volume paths, then test access as the intended non-admin user.
Use a Two-Phase Cutover for Important Data
For a large live NAS migration, first copy the bulk data while the old box remains active. Near cutover, stop or pause writers, run a final incremental/resumable pass, verify the destination, then switch clients to the new box. This reduces downtime and avoids deleting the only good copy too early.
ZimaOS Box-to-Box Migration FAQ
Did the source prove Files is always unreliable for large copies?
No. It documented a 1.5.x failure case. Current IceWhale guidance still uses Files/LAN Storage for NAS migration.
Which current option supports resumable Zima-to-Zima transfers?
The current Backup app can target another Zima device and includes resume/fault-tolerance behavior.
Was rsync the confirmed final method used by the source user?
No. rsync was community advice; the user later said the migration was complete without documenting the final transfer method.
