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

sudo su

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

sudo su

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.

After this run.

Code: Select all

fsck -y /dev/sdxx

Where sdxx is your system partition you restored.

By doing backup 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.

[deck_luck]

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.

Concerning item 2 I am not sure what you are trying to convey. I would NOT recommend anyone use dd to dump the root file system without using a booted Live (standalone) medium and the file system contained in the partition is unmount. Any partition you are dumping with dd should have the file system unmounted. If you fail to do so you are asking for file system meta data corruption as well as user data loss.

Please if you are a new user do not use the dd method and leave it for experienced users. If you make a mistake and specify the wrong sd device name, you can potentially wipe out your file system(s). As Catweazel suggested stick with a gui based clone utility like a standalone Clonezila if you are truly in need of cloning. For a new user using the gui based Clonezilla, you will be less likely to accidentally overwrite your existing installation.

In the previous paragraph the intended audience is new users. So, do not smack my chops telling me the wonders of dd. Yes, dd can be useful for the right job in the hands of the right type of user. And, the dd utility can be used for many things besides dumping a partition.

Often, people joke that "dd" means disk destroyer or delete data. Well, in the wrong hand it can be both.

[asinoro]

Often, people joke that "dd" means disk destroyer or delete data. Well, in the wrong hand it can be both.

I agree that's why it is highlighted with red color!

[deck_luck]

Often, people joke that "dd" means disk destroyer or delete data. Well, in the wrong hand it can be both.

I agree that's why it is highlighted with red color!

So, why are you encouraging a new Linux user like BaronCabbage to use this thread?


Re: Hello.... Is it me you're looking for?

Always Remember, system backup, with Timeshift and check my signature more backups less worries!

Your signature:
Have you backup your system? No! Sorry for you.

We need to protect new user from this.

[Minux1]

A lot of making a mountain out of a mole hill.
It's really not that hard.

[Portreve]

A lot of making a mountain out of a mole hill.
It's really not that hard.

+1

[asinoro]

Often, people joke that "dd" means disk destroyer or delete data. Well, in the wrong hand it can be both.

I agree that's why it is highlighted with red color!

So, why are you encouraging a new Linux user like BaronCabbage to use this thread?


Re: Hello.... Is it me you're looking for?

Always Remember, system backup, with Timeshift and check my signature more backups less worries!

Your signature:
Have you backup your system? No! Sorry for you.

We need to protect new user from this.

The new users are not children, as long we inform them correct there is not problem. At the end every person choose what wants to do!

[DDR-4]

IHMO I cannot fault Clonezilla at all.

It even saved my bacon on a production system that was running 12 Xen VM's when I upgrade the Hypervisor hardware OS from Open SuSE 12.3 to 13.1.

I made a clone of the root partition to a USB stick using a live Clonezilla CD.

After doing an in place OS upgrade there was a bug in the kernel code and the VM's would not start or run correctly. It took me 2 hours to restore the system back to again to the state it was in before trying to upgrade the Hypervisor OS.

Reinstalled the VM's from backups I had made prior to attempting the OS upgrade, and everything booted up first time.

So I'd always recommend Clonezilla for production use as well as home use.

HTH

[Portreve]

While I get the need/want/desire to back up via drive cloning, I just keep my data in a redundant form on external media, which allows me to nuke-n-pave at the drop of a hat. I really don't worry about the rest of it because it's not that big of a deal to set things up from scratch.