One way to prepare for sudden SSD failure
Why SSDs die a sudden death:
https://blog.elcomsoft.com/2019/01/w...-deal-with-it/
There are several ways to prepare for sudden SSD failure.
Here I am using Grsync to manually backup the home folder (/home/fred) regularly to a second drive (/media/drive2).
https://help.ubuntu.com/community/rsync#Grsync
However, one essential refinement must be added to the usual Grsync backup procedure before the drive fails, in order for the home folder (including settings for Firefox and Thunderbird etc) to be restored to a new SSD.
I am sure that more experienced command line users make regular automated backups using rsync in conjunction with Cron:
https://www.howtogeek.com/135533/how...data-on-linux/
It is a good idea to make a note of the current SSD’s existing partition sizes for future use. It is not vital but it can be useful.
Grsync setup:
Source: /home/fred/
Destination: /media/drive2/
Basic options:
Select all boxes except:
1. Ignore existing
2. Do not leave filesystem
3. Size only
4. Windows compatibility
5. Delete on destination
Click on the + , enter a Session name such as fredbackup26thjune2020 and click on OK.
Add any Advanced options that are required or just leave the default setting.
Under Extra options, select Run as superuser.
Click on the cogs icon (top right) for Make a full run (go!), give the user password and then click on Authenticate.
*****Now, here comes the very important addition which makes the difference between Grsync restoring the Home folder subsequently or not.
As soon as the Grsync run has finished, close Grsync.
Next, open the Home folder > View > Show hidden files > .grsync > grsync.ini and click on Copy.
Next, open drive2 > View > Show hidden files > .grsync > grsync.ini.
Copy the Home grsync.ini into drive2’s .grsync folder and click on Replace.
..............................................................................................
In the event of a failed SSD:
Install Linux Mint, or other distro, on a new SSD formatted (use GParted) with similar partitions to the original SSD.
Do Mint updates and also install gedit and Grsync (do NOT run it yet!).
**Use sudo blkid to set up the backup drive (drive2), mounted on /media and modify the /etc/fstab file accordingly. (**Full details are shown below, since it takes up too much space here and is a distraction from the main thrust of this blog).
Open Grsync and reverse the usual set up with:
Source as: /media/drive2/
Destination as: /home/fred/
Use the same Basic Options as above, but with one important addition!
Make sure that for this run only, Delete on Destination is selected.
Under Extra options, select Run as superuser.
Under Advanced options, use the default.
NB Next, copy the original grsync.ini file (for the failed drive) from drive2 into the hidden folder .grsync in the new Home folder, replacing the existing grsync.ini file.
Now close Grsync and then reopen it.
Instead of only default showing in Sessions, there should be a list of previous pre-failure Sessions.
Select the most recent pre-failure Session, such as fredbackup26thjune2020, and then make a full run. Go!
The original Home partition will now be restored to the new SSD.
Make sure that in future Delete on Destination is not selected for:
Source: /home/fred/
Destination: /media/drive2/
........................................................................................
It is also a good idea to regularly check the health of all drives via Mint Menu > Applications > All > Disks.
Also under Drive Options ( ⋮ ) > SMART Data and Self-Tests.
An alternative is to use GSmartControl which works in both Linux and Windows:
https://gsmartcontrol.sourceforge.io/home/
Short and extended self-tests are available, with the output either being viewed or saved.
However, as noted in the first link at the beginning of this article, even an SSD with clean SMART attributes can fail prematurely, so be prepared!
..............................................................................
**Make a New Directory on a Second Drive
1. Find the UUID of backup drive (sdb1) using:
Copy UUID for /dev/sdb1 (without the quotes).
94b3caef-4536-4ba6-ae70-44ca89bbdeb7
2. Create a new directory (drive2), followed by modifications to the /etc/fstab file.
3. Modify /etc/fstab file:
Using the UUID for /dev/sdb1, the section in bold type needs to be added to /etc/fstab.
Example:
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
.................................................................................
# /media/drive2 was on /dev/sdb1
UUID=94b3caef-4536-4ba6-ae70-44ca89bbdeb7 /media/drive2 ext4 defaults 0 0
.................................................................................
# / (root) was on /dev/sda1 during installation
UUID=4a8455b4-7b5a-4365-9267-85bcaf551133 / ext4 errors=remount-ro 0 1
# /home was on /dev/sda6 during installation
UUID=2df03568-787c-418d-b6b5-21c262813c7c /home ext4 defaults 0 0
# swap was on /dev/sda5 during installation
.......................................................................................
NB Make sure all pass numbers are correct.
1 for root, 0 for swap, 0 for /home and drive2.
4. File > Save and Close.
5. Next, mount drive2:
6. Reboot:
7. Then to deal with ownership:
This may take a while, so be patient. If nothing happens after a long time, close Terminal and repeat the command.
.....................................................................................
Pass numbers explained
In fstab what are the <dump> and <pass> fields you left as 0 and 2 respectively? –
The <dump> enables backing up of the partition.
0 disables it.
The <pass> controls fsck checks at boot.
The root should always be 1 and the other partitions are 2 (or disabled using 0).
Also:
The first number indicates whether the file system will be checked by the dump utility. This is usually set to 0, which disables it.
The second number is the priority which will be used by the fsck (file system check) utility at boot. 1 is first - usually for the root (/) file system, and others should be 2 or 0 if you want to disable systematic checks.
.......................................................................................
https://blog.elcomsoft.com/2019/01/w...-deal-with-it/
There are several ways to prepare for sudden SSD failure.
Here I am using Grsync to manually backup the home folder (/home/fred) regularly to a second drive (/media/drive2).
https://help.ubuntu.com/community/rsync#Grsync
However, one essential refinement must be added to the usual Grsync backup procedure before the drive fails, in order for the home folder (including settings for Firefox and Thunderbird etc) to be restored to a new SSD.
I am sure that more experienced command line users make regular automated backups using rsync in conjunction with Cron:
https://www.howtogeek.com/135533/how...data-on-linux/
It is a good idea to make a note of the current SSD’s existing partition sizes for future use. It is not vital but it can be useful.
Grsync setup:
Source: /home/fred/
Destination: /media/drive2/
Basic options:
Select all boxes except:
1. Ignore existing
2. Do not leave filesystem
3. Size only
4. Windows compatibility
5. Delete on destination
Click on the + , enter a Session name such as fredbackup26thjune2020 and click on OK.
Add any Advanced options that are required or just leave the default setting.
Under Extra options, select Run as superuser.
Click on the cogs icon (top right) for Make a full run (go!), give the user password and then click on Authenticate.
*****Now, here comes the very important addition which makes the difference between Grsync restoring the Home folder subsequently or not.
As soon as the Grsync run has finished, close Grsync.
Next, open the Home folder > View > Show hidden files > .grsync > grsync.ini and click on Copy.
Next, open drive2 > View > Show hidden files > .grsync > grsync.ini.
Copy the Home grsync.ini into drive2’s .grsync folder and click on Replace.
..............................................................................................
In the event of a failed SSD:
Install Linux Mint, or other distro, on a new SSD formatted (use GParted) with similar partitions to the original SSD.
Do Mint updates and also install gedit and Grsync (do NOT run it yet!).
Code:
sudo apt install gedit grsync
Open Grsync and reverse the usual set up with:
Source as: /media/drive2/
Destination as: /home/fred/
Use the same Basic Options as above, but with one important addition!
Make sure that for this run only, Delete on Destination is selected.
Under Extra options, select Run as superuser.
Under Advanced options, use the default.
NB Next, copy the original grsync.ini file (for the failed drive) from drive2 into the hidden folder .grsync in the new Home folder, replacing the existing grsync.ini file.
Now close Grsync and then reopen it.
Instead of only default showing in Sessions, there should be a list of previous pre-failure Sessions.
Select the most recent pre-failure Session, such as fredbackup26thjune2020, and then make a full run. Go!
The original Home partition will now be restored to the new SSD.
Make sure that in future Delete on Destination is not selected for:
Source: /home/fred/
Destination: /media/drive2/
........................................................................................
It is also a good idea to regularly check the health of all drives via Mint Menu > Applications > All > Disks.
Also under Drive Options ( ⋮ ) > SMART Data and Self-Tests.
An alternative is to use GSmartControl which works in both Linux and Windows:
Code:
sudo apt install gsmartcontrol
Short and extended self-tests are available, with the output either being viewed or saved.
However, as noted in the first link at the beginning of this article, even an SSD with clean SMART attributes can fail prematurely, so be prepared!
..............................................................................
**Make a New Directory on a Second Drive
1. Find the UUID of backup drive (sdb1) using:
Code:
sudo blkid
94b3caef-4536-4ba6-ae70-44ca89bbdeb7
2. Create a new directory (drive2), followed by modifications to the /etc/fstab file.
Code:
sudo mkdir /media/drive2
Code:
sudo gedit /etc/fstab
Example:
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
.................................................................................
# /media/drive2 was on /dev/sdb1
UUID=94b3caef-4536-4ba6-ae70-44ca89bbdeb7 /media/drive2 ext4 defaults 0 0
.................................................................................
# / (root) was on /dev/sda1 during installation
UUID=4a8455b4-7b5a-4365-9267-85bcaf551133 / ext4 errors=remount-ro 0 1
# /home was on /dev/sda6 during installation
UUID=2df03568-787c-418d-b6b5-21c262813c7c /home ext4 defaults 0 0
# swap was on /dev/sda5 during installation
.......................................................................................
NB Make sure all pass numbers are correct.
1 for root, 0 for swap, 0 for /home and drive2.
4. File > Save and Close.
5. Next, mount drive2:
Code:
sudo mount /dev/sdb1 /media/drive2
Code:
sudo reboot
Code:
sudo chown -R fred:fred /media/drive2
.....................................................................................
Pass numbers explained
In fstab what are the <dump> and <pass> fields you left as 0 and 2 respectively? –
The <dump> enables backing up of the partition.
0 disables it.
The <pass> controls fsck checks at boot.
The root should always be 1 and the other partitions are 2 (or disabled using 0).
Also:
The first number indicates whether the file system will be checked by the dump utility. This is usually set to 0, which disables it.
The second number is the priority which will be used by the fsck (file system check) utility at boot. 1 is first - usually for the root (/) file system, and others should be 2 or 0 if you want to disable systematic checks.
.......................................................................................
Total Comments 0
