What Is the Safest Way to Preserve Timestamps During a NAS Migration?

The safest way to preserve timestamps is to copy with a metadata-aware tool, verify the result, and keep the source unchanged until cutover.

Do not begin with a drag-and-drop move. First decide which timestamps matter, test whether the source filesystem, transfer protocol, destination filesystem, and copy tool can represent them, then run a logged initial copy and a smaller final sync. Modification time is usually portable; creation and change times may not be.

Define Which Timestamps Must Survive

“Preserve timestamps” can mean different metadata on different systems. Linux and Unix commonly expose mtime, atime, and ctime, while NTFS also exposes creation time; the distinctions among mtime, atime, ctime, and creation time determine what can be compared after migration.

Prioritize mtime when users sort documents, photos, or project files by their last content change. Treat ctime as a new-filesystem metadata event rather than creation time, and verify birth or creation time separately because a newly created destination object may legitimately receive a new value.

Use a Metadata-Aware Copy Instead of a Move

On Linux-to-Linux paths, rsync is a common choice because archive mode preserves modification times along with several other attributes. Add only the ACL, extended-attribute, hard-link, or platform-specific flags your dataset needs, and preview the command before allowing deletion or replacement.

On Windows-controlled paths, Robocopy can preserve file metadata, but directory timestamps need an explicit Robocopy option. Avoid a mirror flag until a non-destructive test confirms source and destination direction, because a mirror can repeat deletions as accurately as it repeats files.

Test the Protocol and Filesystem With a Small Dataset

Create a sample containing old and recent files, nested directories, accented names, symlinks if relevant, and known timestamp values. Copy it through the exact SMB, NFS, SSH, local-mount, or application path planned for production; the connection protocol can change the result even when the destination NAS is the same.

Compare source and destination with a timestamp manifest or scripted stat output, not only a file browser. A real-world case shows that CIFS mount behavior can defeat the requested timestamp flags, so a successful command exit is not proof of metadata fidelity.

Use a Two-Pass Cutover and Keep a Rollback Copy

Run the large initial copy while the source remains active, verify file counts, content hashes for a representative or critical set, timestamps, permissions, and application access, then stop writes briefly and run a final incremental pass. Save logs and manifests outside both data trees.

Keep the source read-only or otherwise recoverable for an agreed retention period. Timestamps are only one metadata layer; review extended attributes during a NAS migration before declaring two trees equivalent, especially for macOS, media, and application-managed files.

FAQ

Does rsync archive mode preserve every timestamp?

No. It normally preserves modification time, but atime, creation time, ACLs, extended attributes, and other metadata require separate support or options. The destination filesystem and protocol must also accept them.

Why do folder dates change even when file dates are correct?

Some tools restore file mtimes but update directory mtimes as they create child entries. Test directory timestamps explicitly and enable the relevant directory-copy option when the workflow requires them.

Can timestamps be repaired after the data is already copied?

Often mtime can be corrected from an unchanged source or saved manifest without recopying file contents. Creation time and ctime are less portable, so do not retire the source before confirming the repair path.