All our data files spin around on a nearly full 1 TB drive in a “file server”, a grandiosely overqualified and dirt-cheap off-lease Dell Optiplex desktop sitting in the basement. It’s been running headless and unattended for the last half-dozen years and is badly in need of replacement, so I must copy all its files to a newer, even more overqualified, and equally cheap off-lease Optiplex.
Copying the files from the
/mnt/music collection on the existing server to the identically named directory on the new server proceeds thusly:
sudo mount -o ro fileserver.local:/mnt/music /mnt/nfs sudo rsync -ahu --progress --log-file=/tmp/music.log \ --exclude="/lost+found" \ --exclude=".Trash*" \ --exclude=".dtrash*" \ --delete \ /mnt/nfs/ /mnt/music
Mount the existing collection (from the old server) in read-only mode to avoid heartache subsequent to confusion. It could happen.
The first time through, add a
-n option for a dry run, then inspect the log file for surprises.
--exclude options avoid copying trashed-but-not-yet-deleted files from the various trash directories maintained by various file handlers. In the process of sorting this out, I learned the DigiKam photo manager creates a
.dtrash directory holding deleted files for each of its Album listings, appearing down near the bottom of the top-level album wherein you’ve quasi-deleted photos via “Move to Trash”.
--delete option removes files on the destination (new disk) if they’re not on the source (old disk). I started this migration earlier this year, before the world fell apart, and have moved / consolidated / renamed various directories & files in the interim, so deleting the previous copies from their old locations makes the destination match the source.
So far, so good …