You still show 3TB drive as MBR(msdos) or you will not be able to use the remaining 1TB.
Best to erase, use gparted to convert to gpt, create partition and then rsync.
Tea-for-one’s suggestion on grsync should be good, but I nave never used it.
Older page on grsync, and may go away soon as older pages will be obsoleted. but rsync has not changed.
See also
man rsync
Migrating using rsync …
[1] Partition Table Structure
As mentionned by others, to get full use of the drive you need to recreate the Partition table to be GPT format, using GParted.
Once that is done, you need to recreate you /dev/sdb1 partition as ext4, again using GParted.
I strongly recommend that you give the partition an actual Partition Name, single-word, that could be used again as the name of the directory you will create as a mountpoint.
Lastly, for any internal, permanently installed hard drives, and this is only my opinion, I would recommend a mount root other than the system default, to avoid the system’s automounting logic taking hold when you don’t want it to. For my own, I use the form of /site/${mountdir}, i.e. /site/DB008_F1 and noauto flag in fstab for all other than / and specified drives.
[2] Mount Points
As I understand it, you have the following:
“/media/peter/Seagate Expansion Drive” for mounting /dev/sdb1
(if that name was assigned by you, all good; if not, I recommend manually creating a mountpoint with a shorter name in order to have shorter pathnames resulting from disk searches)
“/media/peter/WD” for /dev/sdc1
[3] Mirror with basic rsync
The most basic form of the rsync command is as follows, for your situation:
(IMPORTANT: You MUST use quotes around any pathname that includes spaces or special characters)
rsync -av /media/peter/WD/ "/media/peter/Seagate Expansion Drive/"
CRITICAL: The source path (first in the above) must end with a “/” to avoid having rsync copying the “WD” directory file itself as another level under the destination directory.
If you want to see “progress”, you need to change “-av” to “-avP” in the above command.
Beyond that very basic and acceptable form, there is a myriad of options to fine tune how rsync behaves. I will again refer you to the first of the links I provided to you in my earlier post for the real case of what I use as an ongoing backup process. Start from where I say “For usage of rsync, …”.
While you still have that master copy (/dev/sdc1), if you need to guarantee that the mirror data is a proper duplicate, not leaving to discovering issues at a later date, there are options which will increase the overall process time because they involve performing checksums. That is for you to weigh the risks regarding how much you trust the basic process.
While most people may not perform checksums (myself included, most times), some people would NOT dream of doing any mirroring without it. So, again, it is dependant upon your personal tolerance for uncertainty/risk or trust in your hardware.
Hope that helps! Good luck!
I do prefer GUI and I am trying GRSync.
But I ran one shot of it setup as I think it should be. but it ran for only a few minutes, ended saying there were Errors and left nothing copied over to the blank backup HDD.
should this (attached) but the correct setup for GRSync?
DANGER!!! do not press the OK!
If the “Seagate Expansion Drive” is your destination drive /dev/sdb1, IT MUST BE THE SECOND REFERENCE, not the first which should be reserved for the data you want to keep.
The image on the wikipedia page is the only example I can find which, to me, makes it obvious that the destination of the copy should be in the second slot (using the word backups in the path).
If you leave it in the first slot, rsync will wipe out your backup data!!! because it is attempting to mirror the source, which in the case you presented, is empty!
For me, that is a failure on the part of the GUI to be specific regarding what should be entered where. 
It is good practice to test a tool on non-critical components/data before commiting to using it for MUST PRESERVE AT ALL COSTS cases.
Since the tool is copying pathname to pathname, you can try the following sequence:
mkdir /tmp/bksrc
mkdir /tmp/bksrc/subdir
echo "test" >/tmp/bksrc/datafile
echo "test" >/tmp/bksrc/subdir/datafile2
mkdir /tmp/bkdest
After using the Grsync tool with the entries
you should find
/tmp/bkdest
/tmp/bkdest/datafile
/tmp/bkdest/subdir/datafile2
I tried using rsync
as a little test I tried to just copy the contents of a small USB stick to my empty backup drive.
my command was:
rsync -av /media/peter/3.3.1-35-amd64/ /media/peter/3TBBackup2/
and it seems to have run and seems to have copied the USB stick.
somewhere.
but nothing shows up on the actual backup drive (3TBBackup2) and when I search for one of the oddball file names, I don’t find it anywhere.
Oh wait. No. Now what?
it seems to have created something new. I now see:
3TBBackup2 (which has my test copy files on it)
and
3tBBackup21 (which is empty)
but under DISKS I only see one partition on that drive.
and on neither of those two…. whatevers do I have Write permission (to create a new folder.)
I’m going nuts
I can’t see clearly enough, but the “21” instance looks like a symbolic link, which means it is a normal file, not a partition.
Also, as presented, the “2” instance is a folder containing what was copied, on a partition of the same name.
“/media/peter” is your systems default target root for “automounts”, what some refer to “plug-n-play”. The system automatically creates temporary names for drives plugged into USB (or other external interfaces). So, if you never specified any entry for the 3TB drive in /etc/fstab, it auto-created a temporary directory for 3TBBackup2 (presumably the assigned “Partition Name” for device /dev/sdb1), then auto-mounted the partition to that directory location.
To avoid confusion of devices, it is always best to create an actual entry in fstab, using UUIDs, for any new device you plan to use regularly, removable or not. That way, you can control where it will actually mount those devices, and if they are mounted every time, or only on demand (“noauto” flag).
I was naming by various play backup drives
3TBBackup3
3TBBackup4
And the one I am currently using…
3TBBackup2
So I think that’s just the name.
Thought what the “21” is I have no idea.
And when I just look (GUI-wise - is that in Gnome?) the contents of
3TBBackup2
I see nothing.
Very confusing (to me)
Before I try to answer your latest post, hoping you have gparted, could you open GParted, select the drive from the drop-down at the upper left, then paste a snapshot of what is presented?
Then, if you right-click on the first ext4 partition, and click the “Information” choice, can you share a snapshot of that window as well?
I’m not clear on what you intended to say there. Do you mean that you do not have write permission on /media/peter/3TBBackup2 ?
The simplest solution to that is
sudo chmod 775 /media/peter/3TBBackup2
sudo chown peter /media/peter/3TBBackup2
Once you’ve done that, you can open your GUI-based file manager, navigate to the location /media/peter/3TBBackup2, the righ-click and attempt to create a folder or empty file. That operation should now be successful.
To confirm what is located where, the report of df for any specified path will reveal if the location is either on root (/dev/sd?1 of root device, under /media/peter, hence not mounted) or another device (/dev/sd?1 different from roots device path).
thank you for taking this time with me. I appreciate it.
here is the Gparted screenshot.
and Information on the ext4 Partition
what I mean is that at the GUI level, I cannot write to that disk
I cannot PASTE a file into that disk as it is currently setup.
when I mount it and then RightClick on …. the area where files are usualy shown
the “New Folder” and “Paste” options are Greyed Out
I was here a few days ago and was told to wipe everything and start again.
and I got the Write ability back.
but now it is gone again.
thank you.
doing those CHMOD and CHOWN seemed to get permissions back
but on 3TBBackup21 not 3TBBackup2
sudo chown peter /media/peter/3TBBackup21
df shows it listed as 3TBBackup21
I am very confused by the naming system now.
it seemed to autogenerate the “3TBBackup21” name (label?) after I tried GRSync
So, as I thought, /dev/sdb1 does have the LABEL “3TBBackup2”.
What I find curious is the fact that there is no mountpoint showing, as per this example:
That usually implies the partition is not yet mounted.
If you right-click on the line for /dev/sdb1 in the first view of GParted, you will have a choice to mount/unmount the device (but that may require that you had an entry for that drive in /etc/fstab).
If no line entry in your fstab, I recommend you create that, then restart the GParted. It should now show the option to "Mount on → " and show the choice of the specified mountpoint. Be sure that mountpoint directory exists before making the attempt.
As another reference tool to examine your setup, you can get all details for mounted partitions with the command:
sudo lsblk --list -o NAME,FSTYPE,PARTLABEL,UUID,SIZE,MOUNTPOINT,SUBSYSTEMS /dev/sdb
which will give a result that looks something like this (depending on your setup):
NAME FSTYPE PARTLABEL UUID SIZE MOUNTPOINT SUBSYSTEMS
sdb 1.8T block:scsi:pci
sdb1 GRUB 1G block:scsi:pci
sdb2 swap DB001_S1 266efd3e-f04d-4ea3-89e6-45e6ac227fa1 1G [SWAP] block:scsi:pci
sdb3 ext4 DB001_F1 5dcf1a96-fa2e-42f5-9a08-37fcce0f0878 195.3G / block:scsi:pci
sdb4 ext4 DB001_F8 46fcb33d-5f0d-423b-b6a7-512c58c76aba 93.5G /DB001_F8 block:scsi:pci
sdb5 swap HIBERNATE d6818877-fcce-4e10-b45c-17d5bf4670b8 6G block:scsi:pci
sdb7 ext4 DB001_F2 7e9a663e-ff1d-4730-8544-c37519056b6f 293G /DB001_F2 block:scsi:pci
sdb8 ext4 DB001_F3 4f7d4192-b136-4a94-b06b-736f76155816 293G /DB001_F3 block:scsi:pci
sdb9 ext4 DB001_F4 7f37ffd4-779a-46c6-b440-f384fb75eb98 293G /DB001_F4 block:scsi:pci
sdb10 swap DB001_S2 3b9a2c7a-67d4-4de7-ae66-214937dc47f4 996.2M block:scsi:pci
sdb11 swap DB001_S3 78b04c8c-8ace-4b46-817d-7059aa1668b7 996.2M block:scsi:pci
sdb12 ext4 DB001_F5 14e15125-6c47-499e-b1a9-734a0f928b5e 195.3G /DB001_F5 block:scsi:pci
sdb13 ext4 DB001_F6 0d416936-e091-49a7-9133-b8137d327ce0 195.3G /DB001_F6 block:scsi:pci
sdb14 ext4 DB001_F7 c2ff9e15-b50e-4c56-9c03-918bf81e0ab5 293G /DB001_F7 block:scsi:pci
I noticed the chmod command you posted was not recursive so first check the owner:group and rwx permissions on the directory with: ls -ld /media/peter/3TBBackup21 then do ls -l /media/peter/3TBBackup21 and check the output the owner:group and permission on the contents..
Confusion is coming in because a directory already exists at
/media/peter/3TBBackup2
when the automounter is trying to create another auto-created mountpoint for the same drive, so it adds a 1, then uses that new mountpoint.
If you create the correct entry in your fstab
UUID=0537f33c-ec60-4a3b-a788-0bce7959d32b /media/peter/3TBBackup2 ext4 defaults,nofail,errors=remount-ro,journal_checksum 0 1
*** check that I typed you UUID correctly, recommend you copy paste from your own system.
you will find that the device is now correctly mounted and accessible.
I believe the chmod should only apply to the mountpoint, because, when doing backups, you want to ensure all other privileges are preserved.
But I think the issue is one of mounting the drive … to provide visibility and access.
I would like to strongly discourage putting static mounts in fstab that point to /media because that’s udisks territory. Messing about in there may have caused the initial confusion with the “21”, because udisks will just append “1” if there is a name conflict.
I think the cleaner and, most importantly, more conscious way is to do manual mounting in /mnt, like so:
$ sudo mkdir -p /mnt/{source,target}
$ sudo umount /dev/sdc1
$ sudo umount /dev/sdb1
$ sudo mount /dev/sdc1 /mnt/source
$ sudo mount /dev/sdb1 /mnt/target
This way you’ll have speaking names and be fully in the loop, which is not always the case with automounter.
Using /dev/sdb etc. is always a little iffy because those names are not guaranteed to always point to the same device, so a simple reboot might shuffle them around, especially with external disks, hence my strong encouragement of using the /dev/disk/by-* hierarchy, e.g. using the /dev/disk/by-id/ symbolic links, which contain the device serial number, which you see in your screenshots, for instance /dev/disk/by-id/usb-57…37-part1, for your WD My Passport.
If both are labeled /dev/disk/by-label is an even better and simpler choice. And since labeling things is always fun, I suggest you do that. 
$ sudo mount /dev/disk/by-partlabel/3tBBackup /mnt/target
...
$ rsync -av /mnt/source/ /mnt/target
Pro-tip: the Tab key is your best friend! You don’t need to type all that stuff manually. It just needs to start with a unique sequence and pressing tab will autocomplete the rest, like so:
$ sud<tab> mount /dev/dis<tab>/by-id/usb-57<tab>-part1
That should, if I’ve counted correctly, give you the 100% correct device name of you WD My Passport.
If nothing happens on the first tab press, the word is not unambigous yet, pressing tab another time will show suggestions
I think, you get the gist.
Linux is case sensitive. Or Capitals matter.
You have /media/peter/3TBBackup2 and label 3TBbackup2.
Automounts are often by label or second small b.
Best to be consistent or totally different so you know which is which.
Often a second duplicate mount is the one with a number at end.
I like to check mounts with (scroll right to see detail as shown in terminal)
fred@dell5310:~$ lsblk -e 7 -o MODEL,NAME,FSTYPE,LABEL,partlabel,MOUNTPOINT,SIZE,fsused
MODEL NAME FSTYPE LABEL PARTLABEL MOUNTPOIN SIZE FSUSED
PC SN530 NVMe WDC 512GB nvme0n1 476.9G
├─nvme0n1p1 vfat ESP EFI system partition /boot/efi 200M 128.3M
├─nvme0n1p2 Microsoft reserved partition 128M
├─nvme0n1p3 ntfs OS Basic data partition 202.4G
├─nvme0n1p4 vfat FAT32 Basic data partition 6G
├─nvme0n1p5 ntfs Shared Basic data partition 63.9G
├─nvme0n1p6 ext4 noble-dell noble-dell / 39.1G 19.2G
├─nvme0n1p7 ext4 data-dell data-dell /mnt/data 142.6G 90.3G
Thank you, Peter, for reinforcing my own point, posted earlier:
Doing as I suggested, you don’t inadvertently “compete” with built-in auto-directives for disk handling.
Full disclosure, my own fstab:
# /etc/fstab: static file system information.
#
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda3 during installation
# /dev/sda3 ext4 DB001_F1 5dcf1a96-fa2e-42f5-9a08-37fcce0f0878 195.3G / INTERNAL
UUID=5dcf1a96-fa2e-42f5-9a08-37fcce0f0878 / ext4 defaults,nofail,errors=remount-ro,journal_checksum 0 1
#
###############################################################################################################
#
###FOREIGN-REF### /dev/sda6 /home ext3 noatime,nodiratime,relatime,errors=remount-ro 0 2
# /dev/sda7 ext4 DB001_F2 7e9a663e-ff1d-4730-8544-c37519056b6f 293G /DB001_F2 INTERNAL
#UUID=7e9a663e-ff1d-4730-8544-c37519056b6f /DB001_F2 ext4 defaults,nofail,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 1
UUID=7e9a663e-ff1d-4730-8544-c37519056b6f /DB001_F2 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 1
# /dev/sda8 ext4 DB001_F3 4f7d4192-b136-4a94-b06b-736f76155816 293G /DB001_F3 INTERNAL
#UUID=4f7d4192-b136-4a94-b06b-736f76155816 /DB001_F3 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=4f7d4192-b136-4a94-b06b-736f76155816 /DB001_F3 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
# /dev/sda9 ext4 DB001_F4 7f37ffd4-779a-46c6-b440-f384fb75eb98 293G /DB001_F4 INTERNAL
#UUID=7f37ffd4-779a-46c6-b440-f384fb75eb98 /DB001_F4 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=7f37ffd4-779a-46c6-b440-f384fb75eb98 /DB001_F4 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
# /dev/sda12 ext4 DB001_F5 14e15125-6c47-499e-b1a9-734a0f928b5e 195.3G /DB001_F5 INTERNAL
#UUID=14e15125-6c47-499e-b1a9-734a0f928b5e /DB001_F5 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=14e15125-6c47-499e-b1a9-734a0f928b5e /DB001_F5 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
# /dev/sda13 ext4 DB001_F6 0d416936-e091-49a7-9133-b8137d327ce0 195.3G /DB001_F6 INTERNAL
#UUID=0d416936-e091-49a7-9133-b8137d327ce0 /DB001_F6 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=0d416936-e091-49a7-9133-b8137d327ce0 /DB001_F6 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
# /dev/sda14 ext4 DB001_F7 c2ff9e15-b50e-4c56-9c03-918bf81e0ab5 293G /DB001_F7 INTERNAL
#UUID=c2ff9e15-b50e-4c56-9c03-918bf81e0ab5 /DB001_F7 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=c2ff9e15-b50e-4c56-9c03-918bf81e0ab5 /DB001_F7 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
# /dev/sda4 ext4 DB001_F8 46fcb33d-5f0d-423b-b6a7-512c58c76aba 93.6G /DB001_F8 INTERNAL
#UUID=46fcb33d-5f0d-423b-b6a7-512c58c76aba /DB001_F8 ext4 defaults,nofail,noauto,data=journal,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,block_validity,nodelalloc,data_err=ignore,nodiscard 0 0
UUID=46fcb33d-5f0d-423b-b6a7-512c58c76aba /DB001_F8 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard 0 2
#
###############################################################################################################
# ROOT DEVICE
# NOT VERY BENEFICIAL -- Too large
# /swapfile swap DB001_S1 UUID=5dcf1a96-fa2e-42f5-9a08-37fcce0f0878,offset=????????? 6G [SWAP] INTERNAL
# /swapfile none swap sw,pri=1 0 0
# /swapfile -->> resume=UUID=5dcf1a96-fa2e-42f5-9a08-37fcce0f0878 resume_offset=37326848
# /dev/sda2 swap DB001_S1 UUID=266efd3e-f04d-4ea3-89e6-45e6ac227fa1 1G [SWAP] INTERNAL
UUID=266efd3e-f04d-4ea3-89e6-45e6ac227fa1 none swap sw,pri=99 0 0
# /dev/sda10 swap DB001_S2 UUID=3b9a2c7a-67d4-4de7-ae66-214937dc47f4 996.2M [SWAP] INTERNAL
UUID=3b9a2c7a-67d4-4de7-ae66-214937dc47f4 none swap sw,noauto,pri=30 0 0
# /dev/sda11 swap DB001_S3 UUID=78b04c8c-8ace-4b46-817d-7059aa1668b7 996.2M [SWAP] INTERNAL
UUID=78b04c8c-8ace-4b46-817d-7059aa1668b7 none swap sw,noauto,pri=20 0 0
# /dev/sda5 swap HIBERNATE UUID=d6818877-fcce-4e10-b45c-17d5bf4670b8 6G [SWAP] INTERNAL
UUID=d6818877-fcce-4e10-b45c-17d5bf4670b8 none swap sw,noauto,pri=1 0 0
#
###############################################################################################################
# SECONDARY DEVICE (DEFUNCT - Ubuntu Desktop a.k.a. GNOME)
#
# /dev/sdc2 ext4 DB004_F1 88fcdce7-c227-4812-b4e6-bcc771ee3809 459.8G /site/DB004_F1 INTERNAL
#UUID=88fcdce7-c227-4812-b4e6-bcc771ee3809 /site/DB004_F1 ext4 defaults,nofail,noauto 0 2
#
###############################################################################################################
# SECONDARY DEVICE (Ubuntu Server + LightDM + MATE + curated list of Application packages
#
# /dev/sdc2 ext4 DB007_F1 06ea0ae0-47d5-43a6-92c6-d54fa5d4b4b3 459.8G /site/DB007_F1 INTERNAL
UUID=06ea0ae0-47d5-43a6-92c6-d54fa5d4b4b3 /site/DB007_F1 ext4 defaults,nofail,noauto 0 2
#
###############################################################################################################
# EXTERNAL DEVICE
#
# /dev/sdc3 ext4 DB005_F1 11c8fbcc-c1e1-424d-9ffe-ad0ccf480128 100G /site/DB005_F1 USB_EXTERNAL
UUID=11c8fbcc-c1e1-424d-9ffe-ad0ccf480128 /site/DB005_F1 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc4 ext4 DB005_F2 a48c6161-986f-4fd9-b127-7d070d86d68f 300G /site/DB005_F2 USB_EXTERNAL
UUID=a48c6161-986f-4fd9-b127-7d070d86d68f /site/DB005_F2 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc5 ext4 DB005_F3 965ad4c7-2f2c-4d8d-8790-0ffb8e18dd1b 300G /site/DB005_F3 USB_EXTERNAL
UUID=965ad4c7-2f2c-4d8d-8790-0ffb8e18dd1b /site/DB005_F3 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc6 ext4 DB005_F4 62026971-3ab4-48c9-bc5b-2b40aa3cc70a 300G /site/DB005_F4 USB_EXTERNAL
UUID=62026971-3ab4-48c9-bc5b-2b40aa3cc70a /site/DB005_F4 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc7 ext4 DB005_F5 c76adc01-99d2-42f9-acba-d0678ee87e8f 200G /site/DB005_F5 USB_EXTERNAL
UUID=c76adc01-99d2-42f9-acba-d0678ee87e8f /site/DB005_F5 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc8 ext4 DB005_F6 4feee7f0-b285-40dc-88de-aafc61433b21 200G /site/DB005_F6 USB_EXTERNAL
UUID=4feee7f0-b285-40dc-88de-aafc61433b21 /site/DB005_F6 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc9 ext4 DB005_F7 0267ec5e-e71b-4eac-b1fa-ec1d92b10400 300G /site/DB005_F7 USB_EXTERNAL
UUID=0267ec5e-e71b-4eac-b1fa-ec1d92b10400 /site/DB005_F7 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc10 ext4 DB005_F8 5b1980b2-df9a-47c6-bedb-df140fbbe8f0 100G /site/DB005_F8 USB_EXTERNAL
UUID=5b1980b2-df9a-47c6-bedb-df140fbbe8f0 /site/DB005_F8 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc2 swap DB005_S1 a668c722-b4db-4d4a-a91b-a01b4faa0fc6 4G [SWAP] USB_EXTERNAL
UUID=a668c722-b4db-4d4a-a91b-a01b4faa0fc6 none swap sw,noauto,pri=3 0 0
#==============================================================================================================================
# /dev/sdc11 ext4 DB006_F1 d827a05e-e151-4ce9-8be4-6f8515a71eab 100G /site/DB006_F1 USB_EXTERNAL
UUID=d827a05e-e151-4ce9-8be4-6f8515a71eab /site/DB006_F1 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc12 ext4 DB006_F2 ef36596a-8566-4a03-8015-2d4f6f8ec7a0 300G /site/DB006_F2 USB_EXTERNAL
UUID=ef36596a-8566-4a03-8015-2d4f6f8ec7a0 /site/DB006_F2 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc13 ext4 DB006_F3 7e9d1316-f988-458d-bd6a-caa8f0ae861a 300G /site/DB006_F3 USB_EXTERNAL
UUID=7e9d1316-f988-458d-bd6a-caa8f0ae861a /site/DB006_F3 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc14 ext4 DB006_F4 14b29e8c-2955-496e-84ca-2f2ef002c070 300G /site/DB006_F4 USB_EXTERNAL
UUID=14b29e8c-2955-496e-84ca-2f2ef002c070 /site/DB006_F4 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc15 ext4 DB006_F5 965e626b-5f45-48b4-b296-efd964307067 200G /site/DB006_F5 USB_EXTERNAL
UUID=965e626b-5f45-48b4-b296-efd964307067 /site/DB006_F5 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc16 ext4 DB006_F6 04fb8fc0-df53-4767-848f-4fbe9d03d79a 200G /site/DB006_F6 USB_EXTERNAL
UUID=04fb8fc0-df53-4767-848f-4fbe9d03d79a /site/DB006_F6 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc17 ext4 DB006_F7 a5f6f5c2-1588-4a8d-b135-9d29f8ae7436 300G /site/DB006_F7 USB_EXTERNAL
UUID=a5f6f5c2-1588-4a8d-b135-9d29f8ae7436 /site/DB006_F7 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
# /dev/sdc18 ext4 DB006_F8 9ed33f4b-76e0-4bab-bf8d-0be444febd17 222G /site/DB006_F8 USB_EXTERNAL
UUID=9ed33f4b-76e0-4bab-bf8d-0be444febd17 /site/DB006_F8 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
#==============================================================================================================================
## /dev/sdd1 on /media/ericthered/VERB_R_F1 type vfat
## (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
## rw,relatime,fmask=0000,dmask=0000,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2
#
# /dev/sdc1 vfat null D4FB-FBCF 28.9G /media/ericthered/VERB_R_F1 USB_EXTERNAL
#UUID=29BF-35A0 /media/ericthered/VERB_R_F1 vfat rw,relatime,codepage=347,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2,nofail,noauto 0 0
UUID=29BF-35A0 /media/ericthered/VERB_R_F1 vfat user,owner,utf8,rw,suid,dev,umask=000,relatime,codepage=347,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2,nofail,noauto 0 0
###
## /dev/sdd1 on /media/ericthered/KINGSTON1 type vfat
## (ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
UUID=5932-FD87 /site/KINGSTON vfat rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,noauto 0 0
###
#UUID=C0E29556E2955210 /site/MyPassport ntfs rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions,blksize=4096,uhelper=udisks2 0 0
#UUID=C0E29556E2955210 /site/MyPassport ntfs rw,nosuid,nodev,relatime,uid=1000,gid=1000,umask=007,blksize=4096,uhelper=udisks2 0 0
UUID=7CB8-B781 /media/ericthered/SLIP_USB vfat user,owner,utf8,rw,suid,dev,umask=000,relatime,codepage=347,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2,nofail,noauto 0 0
###
### TEST ENTRIES
###
UUID=71db8ca8-2ca4-4926-925d-3c378ebe8f1d none swap sw,noauto,pri=3 0 0
UUID=cb8c2a02-a871-46d9-b455-1095d8435c99 none swap sw,noauto,pri=3 0 0
UUID=ae44c502-de89-41c7-bf9e-7b58611d40c3 /site/boot ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
UUID=2af8b0d6-3788-4dd8-95c2-e7399529091c /site/DB008_F1 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
UUID=d835a150-ffb7-44c7-b2ed-a8dbc0d04599 /site/DB008_F2 ext4 defaults,nofail,journal_checksum,journal_async_commit,commit=15,errors=remount-ro,journal_ioprio=2,data_err=ignore,nodiscard,noauto 0 0
Just a suggestion: Try Rescuezilla - it’s Clonezilla with a nice GUI . Much less intimidating