Does the Mainboard/Motherboard of your PC support RAID?
If it does then, simply configure a RAID cluster of 2 drives.
If it doesn’t then, simply configure the spare SSD with a single XFS or ext4 partition – complete disk – and then, mount that partition as “Backup” in “fstab”.
Then create a “home-backup” directory owned by the user “root” in that partition, and then create a sub-directory there named “your username” owned by you.
You can then either create your own backup script with “rsync” commands which can be called periodically by means of systemd or, you can use a graphical backup application such as –
GNOME → “Déjà Dup”.
KDE Plasma → “Back In Time” or “kbackup” or “Kup” (package “kup-backup”) or “luckyBackup”.
Having a “backup” of something on the same disk is of course vulnerable to the disk failing.
Having a “backup” of something on a different disk in the same computer is of course vulnerable to e.g. fire damage to the computer.
Having a “backup” of something in another computer in the same building is of course vulnerable to the destroying of the house by fire or flood or earthquake.
In short, only you can decide against what disasters you want to protect your data. And then you have to design a backup/restore policy to cover that. And after you implemented it, you have to test if it works as intended.
If I correctly recall, the first RAID I saw was in a IBM Mainframe room where there were about 100 disk drives (non-removable – not the things with a stack of 10 platters – and 20 heads – which an operator could remove and replace with a spare one – also a possible backup method … ) – the things about the same size and shape as a washing machine – around about 1981 …
There were a couple of 9-track tape drives in the corner – the things with ½ inch tape on reels and vacuum columns to buffer the tape movement (up to 200 inches per second … ) – up to 2 400 feet per reel …
But, they were only there for copies of critical data which was stored remote from the site.
The big deal then, was to ensure data security on replicated disks without have to employ operators to perform daily backups to tape and, the have data replication “on the fly” – without having to stop the applications executing while the backup was being taken …
Or, having backups, which are usually rotated on a daily basis, located in a secure bank vault physically located at least 50 kilometres from the computer centre …
Yes, and the transports to and from off-line storage taking different routes each day. And almost nobody (even operators) knowing where the storage was, only telephone numbers to ask for a certain medium when a restore was needed where available.
RAID is not a backup is repeated for one very good reason, what happens to one ‘copy’ happens to the other. In every situation except hardware failure, there is no other copy to fall back on. It has to be repeated because if you haven’t been educated on how it works, you blindly look at RAID1 and go ‘great, there’s always this copy of my stuff on this other disk’ and it’s not true.
RAID can protect you from hardware failure, if you’re on top of your monitoring.
RAID can improve usable performance of spinning disks.
RAID is not a backup.
It’s also why cloud synced storage is not a backup.
If you want a backup and you go RAID1, you have made a mistake that is waiting to bite you in the ass.
I do not quite understand why you answer this to me specifically. I never mentioned RAID in my posts above and certainly did not give the impression that RAID is a form of back-up.
They have identical partitioning: EFI System and a single btrfs which occupies 99,9975% of available drive space:
erlangen:~ # fdisk -l /dev/nvme1n1 /dev/nvme0n1
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme1n1p2 1050624 3907028991 3905978368 1.8T Linux filesystem
Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 3907029134 3905978511 1.8T Linux filesystem
erlangen:~ #
Fine grained partitioning still works:
erlangen:~ # fdisk -l /dev/sdb
Disk /dev/sdb: 931.51 GiB, 1000203804160 bytes, 1953523055 sectors
Disk model: SAMSUNG HD103UJ
Disklabel type: gpt
Device Start End Sectors Size Type
/dev/sdb1 16065 67119569 67103505 32G Linux filesystem
/dev/sdb2 67119570 71312534 4192965 2G Linux swap
/dev/sdb3 71312535 176168789 104856255 50G Linux filesystem
/dev/sdb5 176168853 218114504 41945652 20G Linux filesystem
/dev/sdb6 218114568 1953520064 1735405497 827.5G Linux filesystem
erlangen:~ #
Many users stick to this concept of the previous millennium. However it hampers administration and usage of current SSDs and HDDs.
/dev/nvme1n1p2 is the system drive of infamous host erlangen. /dev/nvme0n1p2 is used as the backup drive for the home cloud. All hosts backup their data to this drive using btrbk with its impressive list of key features.
For the case of a fairly modern PC box with 2 identical SSD (non-spinning) drives, what is the better strategy?
For the case of 2 identical SSD SATA drives, a 2 disk RAID will increase the reliability of the system with respect to data reliability affected by SSD array failures over time.
For the support offered by Btrfs, see here – <2.2 Multi-device file system>.
If the 2 identical drives were mechanical – HDD – then a 2 disk RAID can bring a performance plus and, a hardware reliability plus.
For the case of no RAID – one active drive and, one inactive drive only being used for backup –
Yes, provided that, the inactive drive is mounted only when the backup is being taken then, there’s a chance that absolute data security will be better than the case with RAID (Virus attacks, etc … ) but, even if the inactive drive is not accessible during normal system activity – it’s not mounted – it’s still powered on and from the point of view of the SSD arrays, still active …
Therefore, form the point of view of SSD array failures, having 2 identical non-RAID SSDs in a system will not help with the overall data reliability of the system.
And, the operator will have to execute a daily “mount → backup → unmount” task to secure the system’s data.
My private choice –
I’m lazy – born lazy – therefore a simple BIOS/UEFI RAID would be my personal choice for acceptable data reliability given such a system …
"The following assumptions about storage devices are considered
atomicity of reads and writes of blocks/sectors (the smallest unit of data the device presents to the upper layers)
there’s a flush command that instructs the device to forcibly order writes before and after the command; alternatively there’s a barrier command that facilitates the ordering but may not flush the data
data sent to write to a given device offset will be written without further changes to the data and to the offset
writes can be reordered by the device, unless explicitly serialized by the flush command
reads and writes can be freely reordered and interleaved"
All of the above depends on the specific SSD model. Users may want to verify block checksums (btrfs scrub start) and rewrite of all blocks ( btrfs balance start --full-balance).
The above being said users may refrain from using RAID. Both hardware and software RAID add complexity.
On the other hand managing backups with btrbk is robust, reliable and easy to perform. Source and target mounts on infamous host erlangen are fully automatic:
btrbk is ultra fast and and consumes few resources. Backups are sharing blocks. No deduplication is required.
Typical daily internal backup of system (15GB, 469389 objects) and /home (511GB, 908606 objects) finishes in 12 seconds and consumes 8 seconds CPU time.
erlangen:~ # journalctl --since 0:00 -u btrbk
May 28 01:35:49 erlangen systemd[1]: Starting btrbk backup...
May 28 01:36:01 erlangen btrbk[20085]: --------------------------------------------------------------------------------
May 28 01:36:01 erlangen btrbk[20085]: Backup Summary (btrbk command line client, version 0.32.6)
May 28 01:36:01 erlangen btrbk[20085]: Date: Tue May 28 01:35:49 2024
May 28 01:36:01 erlangen btrbk[20085]: Config: /etc/btrbk/btrbk.conf
May 28 01:36:01 erlangen btrbk[20085]: Legend:
May 28 01:36:01 erlangen btrbk[20085]: === up-to-date subvolume (source snapshot)
May 28 01:36:01 erlangen btrbk[20085]: +++ created subvolume (source snapshot)
May 28 01:36:01 erlangen btrbk[20085]: --- deleted subvolume
May 28 01:36:01 erlangen btrbk[20085]: *** received subvolume (non-incremental)
May 28 01:36:01 erlangen btrbk[20085]: >>> received subvolume (incremental)
May 28 01:36:01 erlangen btrbk[20085]: --------------------------------------------------------------------------------
May 28 01:36:01 erlangen btrbk[20085]: /
May 28 01:36:01 erlangen btrbk[20085]: +++ /Btrbk/btrbk_snapshots/Backup/ROOT.20240528T0135
May 28 01:36:01 erlangen btrbk[20085]: >>> /Backup/btrbk_snapshots/erlangen/ROOT.20240528T0135
May 28 01:36:01 erlangen btrbk[20085]: /home
May 28 01:36:01 erlangen btrbk[20085]: +++ /Btrbk/btrbk_snapshots/Backup/home.20240528T0135
May 28 01:36:01 erlangen btrbk[20085]: >>> /Backup/btrbk_snapshots/erlangen/home.20240528T0135
May 28 01:36:01 erlangen systemd[1]: btrbk.service: Deactivated successfully.
May 28 01:36:01 erlangen systemd[1]: Finished btrbk backup.
May 28 01:36:01 erlangen systemd[1]: btrbk.service: Consumed 8.051s CPU time.
erlangen:~ #
External backups are done the same way. They are slower (USB C), but as reliable as the internal backup.
