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/musicMount 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.
The various --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”.
The --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 …
The Smell of Molten Projects in the Morning 