Hi All, Here is my fstab after the install, it seems that my two "RAID" drives are just "dwellers on the threshold" as they do not appear in fstab. alg@andrewg:~$ sudo cat /etc/fstab [sudo] password for alg: # /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 UUID=2dfcd965-625b-47d5-a267-b02276320922 / btrfs defaults,subvol=@ 0 1 # /home was on /dev/sda3 during installation UUID=2dfcd965-625b-47d5-a267-b02276320922 /home btrfs defaults,subvol=@home 0 2 # swap was on /dev/sda2 during installation UUID=b2c6d1c4-4b94-4171-954e-9f5d56704514 none swap sw 0 0 alg@andrewg:~$ Are these two following commands OK to apply to drives that were balanced previously and hold data? sudo btrfs device add -f /dev/sdc1 /data sudo btrfs ballance start -dconvert=raid1 -mconvert=raid1 /data and will issuing those commands write that into fstab? Many thanks Andrew On 18/1/20 12:59 pm, Craig Sanders via luv-main wrote:
On Fri, Jan 17, 2020 at 11:36:29AM +1100, Andrew Greig wrote:
I recently experienced an SSD failure, and so I have purchased another to set up my system again. I received some substantial help from this list early in 2019 to build my machine with this SSD as / and /home under Ubuntu 18.04 with two x 2Tb conventional drives in RAID for storing my work, all are running btrfs. You lost your home dir and the data in it when your SSD failed Because your rootfs and /home on the SSD doesn't have any redundancy (i.e. it was a single partition, with no RAID). I strongly recommend setting up a cron job to regularly snapshot it (at least once/day) and do a 'btrfs send' of that snapshot to a sub-volume of your /data filesystem.
That way you won't lose much data from that partition if your SSD dies again - you can retrieve it from the last snapshot backup, and will only lose any changes since then.
If your / and /home are on separate partitions (or btrfs sub-volumes) you will need to do this for both of them.
(if you weren't running btrfs on /, you could do this with rsync instead of 'btrfs send', but rsync would be a lot slower)
IME, drives are fragile and prone to failure. It's always best to make plans and backup procedures so that WHEN (not IF) a drive fails, you don't lose anything important...or, at least, minimise your losses.
Also, remember that RAID is not a substitute for backup so you should regularly backup your /data filesystem to tape or other drives. Ideally, you should try to have an off-site backup in case of fire/flood/etc (e.g. backup to an external USB drive and store it at your office, lawyer's safe, a friend's house or somewhere. Have at least two of these so you can rotate the offsite backups).
After the machine was running I was asked if I had set up the machine using Ubuntu Server, I hadn't, because at that time I didn't see those options.
I am thinking, then, for this build, perhaps I should set it up using Ubuntu Server. I will need to get my system to recognise the RAID drives as well. If the installer doesn't automatically detect your /data btrfs filesystem and add it to /etc/fstab, it's easy enough to add it yourself.
So before I jump in the deep end again, are there any "gotchas" of which I should be aware.
Will the server version make life more reliable? the only significant difference between the server and desktop versions of ubuntu are the packages which are installed by default. e.g. the desktop version installs a whole bunch of desktop stuff (X, desktop environment and GUI apps, etc) that the server version doesn't. Otherwise, they're the same - same kernel, same libc and other standard system libraries, etc.
craig
-- craig sanders <cas@taz.net.au> _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main