How to Update and Secure your System

[asinoro]

This is my personal opinion.
Updates are important according the needs of the user and the system.
Linux Mint compare with all the other Linux Distros has the most flexible and Democratic Update Tool, where the user can choose what to update, upgrade or not.

But to update, upgrade the system has always risks, thus always backup it is the most secure way to protect the system.
TimeShift and all rsync based tools they have limitations.
The most secure and reliable way of backup is Clone Backup, which copy all the sectors of the partition or hard drive, which means if the source is defective the backup will be also.

To have a reliable Clone Backup you must be disconnected from the Internet and avoid any use of the system.
The most simple and reliable way, it is the use of the native tools of the system dd and gzip.

The Clone Backup with dd and gzip has three great advantageous together.
1. It copies exactly all the partition something rsync can not.
2. It does the job from a running system not a live medium, the user don’t need to leave the running system.
3. It stores the partition in a .gz file, in a place whatever the user choose, other partition, hard drive, usb.

dd is powerful command and if you do a mistake by choosing wrong partition or drive it will delete all the destination’s data.

From running system the below command does the job, as root:

Code: Select all

dd if=/dev/sdxx bs=4096 conv=notrunc,noerror | gzip > /media/location_of_storefile.gz 

Where sdxx is your system’s partition and /media/location_of_storefile.gz the path where the file is and storefile.gz, the name of the file.

To restore your system follow the above suggestions and from live USB or another Linux OS, as root:

Code: Select all

gzip -dc  /media/location_of_storefile.gz | dd of=/dev/sdxx 

Where the location of the file /media/location_of_storefile.gz and sdxx the location of the system’s partition.

By doing this regularly your system will be above all secure!

Clone Backup and TimeShift

Since TimeShift is the default rsync Backup method on Mint 18.3, it can work fine with the restored clone image of the backup. How it can work.
It is suggested after you installed your OS to make one image file .gz with Clone Backup and to check if the image is correct and the restore OK. This is very important.
Soon or later you will experience that the restore with the TimeShift will not solve the problem you have.
Instead to reinstall your OS, first you restore the backup Clone image file .gz then the TimeShift and your problem will be gone.

The magic world of Linux makes miracles.

[Jim Hauser]

I always back up from an independent distro, either from the DVD or something on another drive. This way nothing on the on the system being backed up is running.

This method is "old school" and may be outdated by now but it works perfectly for me.

[catweazel]

To have a reliable Clone Backup you must be disconnected from the Internet and avoid any use of the system.

You've obsiously never used PartedMagic or Clonezilla live.

I snipped the rest as it's dangerous and completely unnecessary.

[asinoro]

To have a reliable Clone Backup you must be disconnected from the Internet and avoid any use of the system.

You've obsiously never used PartedMagic or Clonezilla live.

I snipped the rest as it's dangerous and completely unnecessary.

The Clone Backup with dd and gzip has three great advantageous together.
1. It copies exactly all the partition something rsync can not.
2. It does the job from a running system not a live medium, the user don’t need to leave the running system.
3. It stores the partition in a .gz file, in a place whatever the user choose, other partition, hard drive, usb.
I add this to the tutorial.

[asinoro]

I add Clone Backup and TimeShift

[linx255]

The Clone Backup with dd and gzip has three great advantageous together.
1. It copies exactly all the partition something rsync can not.

I know from personal experience dd can be dangerous and unnecessary, and it's not useful if you're trying to use one OS image to manage two 'identical' OS partitions because it will cause inodes to be shared across partitions, resulting in absolute mayhem and destruction, unless for some reason you just want each inode to be accessed from two partitions, and even then I'm not sure that wouldn't make a mess of your system. One could rsync files out of a mounted ISO image instead of using dd to write, but then why not rsync it out to begin with? Rsync is good, except for some reason it randomly hangs every now and then ( apparently ) due to bugs ( not sure if rsync or my OS / hardware ), and it's slow if you need to checksum, which can matter on occasion. So I've ditched rsync, but if you want to try it, I used to use this command: rsync -vAXcad --progress --delete --exclude=.Trash-1000 --exclude=lost+found

While not as pretty as a backup program with a GUI, I've built my own scripts to automate backups with good old 'rm' and 'cp' commands; it didn't take much time or expertise piecing together the commands and it does exactly what I need fast and reliably. Having fine controls helps because I don't always need to backup an entire partition or drive or folder and I can make scripts or options for the what I need most and if I need any finer control than that I can just manually back it up, which I almost never have to do. I have two sets of scripts: one to image the OS partition and another to backup both OS images and user data, though it could all be bundled together as one if you have one partition. Once I built the scripts backups have never been so perfect and easy and it's rockstar awesome.

I found I don't need tar / gzip unless I'm going to also encrypt a bundle of files. I think it's best if the files just kick it in the open file system which makes access easy, less prone to errors ( since I have had tar / gzip files go bad and ruin the whole bundle ), and it saves time from having to zip / unzip.

[Sugarcrisp]

Hello Linx255...I would be interested in taking a look at your backup scripts if they are available.

[linx255]

Assuming you're using a USB-mountable drive that mounts to /media/{user}/{mountpoint}, for each directory you want to backup, you may:

Code: Select all

# rm is optional; I use it to be darn sure the old copy is gone and doesn't linger for any reason or cause any permissions errors.
# You may or may not need sudo depending on your directory permissions.
rm -rf /media/{user}/{mountpoint}/{root_directory_on_destination}/{directory}
# Recreate the directory on the backup drive to ward off any 'directory does not exist' errors.
mkdir -pv /media/{user}/{mountpoint}/{root_directory_on_destination}/{directory}
# Copy directory
cp -rpv /{root_directory_of_source}/{directory_to_backup} /{root_directory_on_destination}/{directory}

^ Something like that. Very simple, works every time, reliably, and super fast.

I avoid just copying * because long or large copy operations can fail, so you may break down copy operations into smaller ones, and if reliability is an issue you can always log errors from your cp commands.

If you want to prompt yourself to skip a certain directory, insert the following before the above code:

Code: Select all

echo "Skip {directory}? ( Y / N )"
read t
case $t in
  [0]) echo "Skipping {directory}" ;;
  [1]) the above rm, mkdir, and cp commands separated by ; and ending this line with ;;
esac

Make sure the drive is mounted properly and that the mount point you specify in the script is what the drive is mounted to because sometimes the drive won't necessarily mount to the same place reliably ( i.e. when auto-mounting ) and your copy operation will go transfer the files into a directory on your source drive instead of your backup. If you want to manually mount the drive in your script, you can first unmount it via 'sudo umount' and specifying the /dev/sdX designation ( which also tends to change ), or the UUID or disk label ( I think; I forget; do check me on that ), or otherwise add caja /media/{user}/ or mount | grep /media/{user} to check for the correct mountpoint, and copy and paste it into your script if you want to be really careful. Then use 'sudo mount' to mount it as you see fit.

You also want to check and make sure your source hasn't been accidentally deleted or corrupted, otherwise you'll backup your nothing, overwriting your only copy of your something with nothing! I've built in this command to open caja to allow me to just quickly check my files are there: caja {directory_to_check} /{directory_to_check} etc etc and then you can then X those windows out and return to your script. If I wanted to be slicker I could just do an 'ls -al' command in the script for each directory / file I want to verify.

And that's basically it.

[Sugarcrisp]

Thanks Linx255, I will check it out.