I decided to finally be proactive about replacing the externall HDD that holds all my media files with a new drive before the existing one craps out. So I now have the newer version of my existing drive, same capacity, formatted (via drive-manager) as ext4 and mounted on my Pi3. Existing drive is at /mnt/media, and the new is at /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb.
I’m planning to use rsync to copy everything in media/ from existing to new, the hope being that I can then just unmount the existing drive and mount the new one in its place without any interruption to my arr apps and sab.
My question: How best to proceed in order to achieve my end goal? In order for my plan to work, do I need to rename 1627f155-5a19-4bc8-80ee-1e01ff08b8cb to media?
Thanks for any tips you can pass along!
Easiest thing would be put both of em on your system unmount the new drive
How to Clone Your Linux Hard Drive: 4 Methods (makeuseof.com)
Create the new drive (you already did that)
Add to Your Existing Linux Server (howtogeek.com)](https://www.howtogeek.com/devops/how-to-add-a-new-drive-to-your-existing-linux-server/)
then dd everything over to the new drive bit for bit copy to new drive (no need to use rsync
dd if=/dev/sda of=/dev/sdb bs=128M conv=noerror,sync
Make 100% sure you put old drive then new drive in the above command, or it can do bad things to your old drive (aka wipe it)
Then get the UUID of the drive and modify your /etc/fstab, replace the old drive UUID with the new drive UUID, then reboot and it should come right up on the new drive and run just like it was always there
ls -l /dev/disk/by-uuid/
or
blkid
You won’t need to rename anything…it’s a bit for bit copy of the entire drive
2 Likes
What about using a daily dietpi-backup and set the filter options so that only your needed files are copied?
See also DietPi tools - DietPi.com Docs and DietPi-Backup in an multi-device environment - DietPi blog.
1 Like
dd is much too slow and dietpi-backup is much too complicated for this simple task. rsync is the perfect tool for this, with -a option to preserve all metadata, symlinks etc. After done with the sync, unmount the old drive and mount the new drive to /mnt/media and everything will work as before. So yes, in /etc/fstab the new drive needs to have /etc/fstab if you mean that. Its UUID is fixed but its mount point/path can be freely chosen.
1 Like
Thanks for this. So:
rsync -a /mnt/media /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb
Then, via drive-manager, unmount /mnt/media (maybe stopping sab and the arr apps first, just in case?) and change the mount point for /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb to /mnt/media?
Here, FWIW, is what my fstab currently looks like:
#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=c26b8af2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=c26b8af2-01 /boot vfat noatime,lazytime,rw 0 2
UUID=f02d7604-01a9-4326-8758-532d31affa4d /mnt/media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=1627f155-5a19-4bc8-80ee-1e01ff08b8cb /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
Thanks again for your help!
yes stopping all services would be good
dietpi-services stop
swapoff -a
mount -o remount,ro /mnt/media
Hopefully last step is working as it will put /mnt/media into read only mode.
Once done, /etc/fstab can be adjusted a follow:
UUID=f02d7604-01a9-4326-8758-532d31affa4d /mnt/media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=1627f155-5a19-4bc8-80ee-1e01ff08b8cb /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
into
#UUID=f02d7604-01a9-4326-8758-532d31affa4d /mnt/media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
UUID=1627f155-5a19-4bc8-80ee-1e01ff08b8cb /mnt/media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
2 Likes
Thanks, that last bit on modifying fstab was what I wasn’t sure about; didn’t imagine it would be as simple as commenting out the old drive association. Nice.
One more bit of clarification:
After
dietpi-services stop
swapoff -a
mount -o remount,ro /mnt/media
and
rsync -a /mnt/media /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb
What will the new drive look like when I CD into it? Will it be /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb/media?
If you finish the data copy and adjusted /etc/fstab, your data will be available on /mnt/media as it was before after reboot.
2 Likes
So the two fstab steps are:
- comment out the old mnt/media
- change 1627f155-5a19-4bc8-80ee-1e01ff08b8cb to media
And then a reboot, I suppose, which will restart all my services and magically find my new drive via fstab.
The reason I asked about what the mount would look like is because I came across this:
So, for example, if you want to copy some files under your home directory to a USB storage device, you might use rsync -a /home/user/dir/ /media/disk/dir/. By the way, “/home/user/dir/” and “/home/usr/dir” are not the same thing to rsync. Without the final slash, rsync will copy the directory in its entirety. With the trailing slash, it will copy the contents of the directory but won’t recreate the directory.
So I assumed the rsync command above would copy the /media directory to the drive, but I couldn’t figure out where…
@MichaIng could you check correct rsync syntax to move whole content from /mnt/media to /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb. Thx
1 Like
FWIW, I just tested quickly in OSX, and omitting the trailing slash on /mnt/media does, in fact, copy the directory (media) and its contents. Including the trailing slash copies the contents of the directory only.
So, the command I (probably?) want is:
rsync -a /mnt/media**/** /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb
Then, the contents of media will be in 1627f155-5a19-4bc8-80ee-1e01ff08b8cb on the new drive, and when I rename it to media in fstab, I should be golden. Hmm. Except, I guess, that I won’t get the permissions copied over for the media directory, which I’ll probably want.
1 Like
yes you need to copy the content of media and not the folder itself.
1 Like
Thank you. Do you think I should change the permissions, owner, and group for the target location before or after the rsync?
drwxr-xr-x 7 root root 4096 Feb 1 18:20 .
drwxr-xr-x 18 root root 4096 Jan 20 18:03 ..
drwxr-xr-x 3 root root 4096 Feb 1 18:17 1627f155-5a19-4bc8-80ee-1e01ff08b8cb
drwxrwxr-x 9 dietpi dietpi 4096 Sep 5 10:27 dietpi_userdata
drwxrwxr-x 2 dietpi dietpi 4096 Jul 31 2022 ftp_client
drwxrwxrwx 7 dietpi dietpi 4096 Mar 9 2019 media
drwxrwxr-x 2 dietpi dietpi 4096 Jul 31 2022 samba
Can be done afterwards if needed
1 Like
Well, I got all the way to the rsync step and got this:
dietpi@DietPi:~$ rsync -a /mnt/media/ /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb
-bash: rsync: command not found
dietpi@DietPi:~$
I guess using dietpi-sync instead of rsync will install rsync, sounds like? Will dietpi-sync - a function the same as rsync -a?
I ran dietpi-sync, which ran the update to install rsync, then just exited out of it once it opened. Then ran
rsync -a /mnt/media/ /mnt/1627f155-5a19-4bc8-80ee-1e01ff08b8cb
which appears to have started the process. I probably should’ve added some sort of output so I know when this is done running.
I think everything completed, but I can’t figure out how to confirm without powering down the old drive. One confusing thing:
After completing the rsync (I think it completed?), I modified fstab; it now looks like this (after a reboot):
PARTUUID=c26b8af2-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=c26b8af2-01 /boot vfat noatime,lazytime,rw 0 2
UUID=1627f155-5a19-4bc8-80ee-1e01ff08b8cb /mnt/media ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
dietpi-drivemanager looks like this:
/ : /dev/mmcblk0p2 | ext4 | Capacity: 29.2G | Used: 3.5G (12%) │
│ /boot : /dev/mmcblk0p1 | vfat | Capacity: 126M | Used: 34.9M (28%) │
│ ●─ sda ──────────────────────────────────────────────── │
│ /mnt/media : /dev/sda1 | ext4 | Capacity: 1.8T | Used: 825.9G (45%) │
│ ●─ sdb ──────────────────────────────────────────────── │
│ /mnt/f02d7604-01a9-4326-8758-532d31affa4d : /dev/sdb1 | ext4 | Not mounted │
│ ●─ Global Options ─────────────────────────────────────────● │
│ Idle Spindown : Set a global idle duration, before drives power down │
│ ●─ Add / Refresh Drives ───────────────────────────────────● │
│ Add network drive : Select to mount networked drives │
│ Refresh : Scan for recently added/removed drives
But when I do ls -la on /mnt/, I get:
dietpi@DietPi:/mnt$ ls -la
total 28
drwxr-xr-x 7 root root 4096 Feb 1 18:20 .
drwxr-xr-x 18 root root 4096 Jan 20 18:03 ..
drwxr-xr-x 2 root root 4096 Feb 1 18:20 1627f155-5a19-4bc8-80ee-1e01ff08b8cb
drwxrwxr-x 9 dietpi dietpi 4096 Sep 5 10:27 dietpi_userdata
drwxrwxr-x 2 dietpi dietpi 4096 Jul 31 2022 ftp_client
drwxrwxrwx 7 dietpi dietpi 4096 Mar 9 2019 media
drwxrwxr-x 2 dietpi dietpi 4096 Jul 31 2022 samba
Should I still be seeing that “old” UID for the new drive and media?
I guess you mixing thinks.
Folders shown in /mnt/ are directories only. These are just names. There is no relation between folder name and device UID. The device UID is not going to change just of a file copy or a different mount point. Best overview is following
lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
This will show which device is mounted to which point, having which device ID
1 Like