SYSTEM restore

[TANUJMINTLINUX]

although i know that people here hardly likes Windows but still i appericiate one point in that OS.
That thing is system restore.
I recommend that MINT should have a facility like system restore.From my experiences i can tell newbies and even experts run their systems in trouble.With system restore there will be an onhand solution of breaking a system .
so , i recommend it as an important security feature.
And it will also serve the purpose of making a user freindly OS


and even i don't like WINDOWS
also do vote whosoever reads this post

[WinterTroubles]

Please excuse me if I'm being dumb, but isn't Windows system restore just a configuration back up? It's my understanding that setting a cron job to back up all of your systems config files through something like luckybackup would perform exactly the same function with the bonus that you would be able to store the backed up files externally.

[clfarron4]

Please excuse me if I'm being dumb, but isn't Windows system restore just a configuration back up?.

That's what I thought. Yes, Windows has other facilities, but you have to set those up.

There are many ways to do a backup. Off-hand, the ones I can think of are:

• cron
• rsync
• lvm
• btrfs

There are more. and I think it'd be up to the user to choose the best on for their needs. The ArchLinux Wiki does a pretty good job of explaining how they all work.

[Habitual]

I did not vote.

Why? Linux is already a "friendly OS" and Mint especially so, even though I don't use it.
Learning to make regular and reliable backups is a lesson every user of any System is required to take.

Experience is what you got by not having it when you need it.

No magic button is going to replace experience.

[thupten]

Use "Backup Tool" to create backup for your files or system configurations.
Menu > Administration > Backup Tool

[bleekii]

Use "Backup Tool" to create backup for your files or system configurations.
Menu > Administration > Backup Tool

The backup tool is not a replacement for a system restore tool. In fact it's not even a good backup tool except in the case of upgrading mint or backing up your home directory. It relies on a re-installation of the OS for recovery.

Ideally a system restore tool would:
-Make a daily or weekly backup of all system and configuration files
-Keep backups those for a set amount of time
-Be able to run from grub

A good starting point would be a modified versions of "Backups." The problem is that Backups doesn't have a default configuration for this task and you can run it from grub. I searched for information on what directories I should exclude. I backup my root directory daily but exclude /home, /media, /dev, /proc, and /sys. The problem is, I have no idea if this will work should a problem occur!

[xenopeek]

Ideally a system restore tool would:
-Make a daily or weekly backup of all system and configuration files
-Keep backups those for a set amount of time
-Be able to run from grub

That's a horrible way to go about it, wasting disk space and performance to make all those backup sets (not to say write cycles on SSDs, which have become ubiquitous). Btrfs filesystem provides a much better approach to this, with snapshotting of entire filesystem or directory that don't take up any disk space or performance till a file on it is changed (using COW - copy on write - mechanism). And yes you can boot from snapshots.

This is exactly what SUSE uses, making a snapshot before and after installing a package upgrade and before and after changing any system configuration through its configuration tool. (Article from years ago, but summing up nicely how all this works together: https://www.suse.com/communities/conver ... es-11-sp2/). Linux Mint doesn't support Btrfs in its installer. Hopefully the developers will roll back the blacklisting of Btrfs with Linux Mint 18 installer, and that would open up the path to something like this. It still needs a tool like SUSE's snapper to manage snapshots, and would need to be tied in with package management tools and system configuration tools. Or replace it with a daily snapshot that would also work (but this gives less granularity).

Ubuntu's next package management system, Snappy, would also already be a help for the goals sought. It provides easy roll back of package upgrades. I doubt we'll see that on Linux Mint 18 as Linux Mint developers are conservative in their adoption of new OS level technology.

Anyway, system restore isn't going to be something out of the box on Linux Mint I think. It's hard to get right for all situations. Anybody needing system restore on Linux Mint, thus not using Btrfs or other COW filesystem, will be stuck on making recurring (wasteful) backups. Of course there are some smart tools here also, that make incremental backups for example, but that won't approach COW efficiency by a long shot. Here is a review of some of the "System Restore" / "Time Machine" like backup solutions for Linux: http://www.nuxified.org/blog/easy-linux ... ctionality

[bleekii]

That sound perfect, xenopeek! Do you any feeling about the possibility of Mint allowing btrfs in the future?

[xenopeek]

Not before Linux Mint 18 at least. It will depend on Linux Mint developers changing the blacklist that is currently in the installer, and Ubuntu developers bringing btrfs related packages up to usable versions in the next LTS package base. There are folks that have managed to install Linux Mint 17 on btrfs so it is possible, but because of LTS package base (=old and stale versions of all packages) the btrfs related packages don't have the latest improvements so I wouldn't recommend it. Btrfs is much more usable on Fedora or Arch Linux right now. I'd wait till Linux Mint 18.

[bleekii]

I'm so looking forward to that! I'm stuck with a semi-functioning Betsy. I can't even use 17 because of poor hardware support

[reddot]

i dont really like the idea of system restore, i have NEVER used system restore in windows xp. In windows 7, i used it recently a few weeks ago i was selling my old laptop and installing back the original os windows 7. I did a clean install and windows update would not update, it just kept searching for updates after service pack 1(i also installed other 3rd party stuff). Did a system restore and guess what, it does not work. I had to reinstall windows 7, i did try to use a windows update fix, did not work, registry fix, nothing. Is it much easier in 8/8.1?, i dont know i hate windows 8/8.1,
but is system restore/refresh customizable?. I HATE SYSTEM RESTORE in windows fixes what? every time i use it nothing works, the system is still in a unstable state, i must really fudge it.
i have really bad experience with windows, linux is way faster and easier, i love using the terminal by the way, i love control.
and i hate the fact that i had to go digging for more settings using a folder called
God-Mode.{ED7BA470-8E54-465E-825C-99712043E01C}

I personally use Aptik. I love it because i get to choose exactly what gets installed or backup ppa, pkg cache, pkg, themes, config(i dont use config i clone my home folder).
You should never store backups in the main drive, i currently have 2 enterprise nas drives for that. i learned the hard way
The stock backup tool in system-->administration looks ok in linux mint 17.2 mate, i havent used it not sure it backs up ppa.

In linux theres lots of choices, also in wondows but most are not free/open source
either way installing linux only takes less than 5 mins on a ssd. and since i backup apt cache i install updates in minutes.
I bet theres a faster way i just like the whole idea of a "clean install", thanks to microsoft TRAUMA

[linx255]

This is long a read I realize, but this may work as an interim solution until btrfs and snapshots are implemented...

Windows System Restore manages configurations, in a very generic, one-size-fits-all, way, because Windows was designed for users who don't have as specific needs as Linux users, since the whole point of Linux is fine control.

Windows System Restore blows because it's not a complete, comprehensive recovery, and it won't necessarily wipe out malware on the file system or fix certain kinds of system breaks.

With Linux there are a million different types of systems and users all with different needs, and there's no one way to implement a system restore feature.

There are programs to backup and restore systems, but I personally require finer control and efficiency, and I like to backup the entire file system because sometimes our system gets hosed and we don't know where / why and there is no repair tool in the world that will ever recover our installation even if we restore all config files.

Here's what I do since Mint doesn't support Btrfs and snapshots yet. ( I use a Bash script to automate this because I want to spend as little time typing out commands as possible in the future. We can do this manually in the terminal though, and still save ourselves a lot of trouble from having to re-install everything from scratch. )

1) Partition hard drive with two equally-sized OS partitions ( Mine are ~20G ) and for best results a dedicated /boot partition, which is extremely easy to create in Mint setup or gparted. ( I always format the drive with gparted prior to Mint setup for more precise control over partition sizes. )

2) Setup Linux Mint on the primary just the way we like it.

3) Boot into LiveCD and make an .iso image of the installation with 'dd' command. We can maintain different versions of images too, if desired ( can be time-consuming without automation, though luckily automation is easy enough ). Depending on how we want to image our drive our 'dd' command may vary. But generally, I'd do:

Code: Select all

dd if=/dev/sdaX of=/"our directory/.iso image here"

of course replacing "X" with the appropriate number, or the "a" in "sda" with b, c, d, or whatever drive we're working with.

I should note we never want to create the image of a drive we're currently booted into!

4) Once we have the .iso image, mount it and rsync it to the second partition, assign a new UUID to it with tune2fs and update /etc/fstab. Also make sure Grub is configured to boot into either partition, if desired; it helps to have this dual-boot capability. If we don't update the UUID and /etc/fstab then I'm guessing Grub will produce an error on boot. Also never use 'dd' to restore the image of the primary to the secondary, because all the files it creates will actually be hard links; that is, sharing the same inodes--which will wreak havoc on our system, I discovered after much calamity and investigation. Only use rsync. If we don't mount and rsync as root we'll lose some files in the transfer, I'm almost positive. Here are my commands:

Code: Select all

sudo mount /dev/sdaX /"our mount point here"
cd /"the directory our .iso image is mounted to"
sudo rsync -cgHiloprstvx --temp-dir="our temp directory here" --progress --delete --exclude=.Trash-1000 --exclude=lost+found --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/media/*,/lost+found} --delete --ignore-errors * "our destination here" | sudo tee "our log file here"
sudo tune2fs -U our_unique_UUID_here /dev/sdaX 

Of course, the tune2fs command should point to the secondary partition.
And then we may finally edit /etc/fstab on that drive to reflect the UUID changes:

On the primary, fstab should have:

Code: Select all

UUID=unique_UUID_for_sda5_for_example  /         ext4  0  1
UUID=unique_UUID_for_sda6_for_example  /sda6 ext4  0  2

On the secondary, we flip flop it:

Code: Select all

UUID=unique_UUID_for_sda6_for_example  /         ext4  0  1
UUID=unique_UUID_for_sda5_for_example  /sda5 ext4  0  2

As shown above we'll change the mount points and the drive that mounts to / should be set to the "1" value on the last # parameter, and the others to 2, at least with a traditional setup.

5) We may want to generally boot into the primary partition for normal use unless we're doing maintenance on it, like redoing the image of it, or restoring the image to it to wipe out any problems we were having. If we're booted into the secondary and we've just finished redoing our image, we can boot back into the primary and "restore" ( sync ) the newly updated image to the secondary with the same commands in step 4. We don't actually need a second partition to do any of this; LiveCD works, but I like not having to rely on LiveCD because it's easier and cooler to just have a second partition without the USB performance limits, the LiveCD OS restrictions, and all your settings already there. Plus, if you've disabled USB boot on BIOS for security then it's a pain to enable every time you need to do this maintenance via LiveCD/USB.

6) If we want to get more advanced we can manage multiple versions of our images, which I recommend, because we may mistakenly update our image with an undiscovered fatal break and then we've lost our installation. On my data partition I have a folder called 'dumps' which contains the following images:

"fresh.iso" = freshly installed Mint ( useful after setting up Mint for the first time in case we screw things up as we customize and tweak; I never use this image but it's there if I decide I want to change something after a fresh install and don't want to have to re-install all over. Using dd with this file to install Mint is slower than a fresh install, but eliminates the need for human involvement and it remembers all our setup customizations, which is handy if you're only using one kind of machine. )

"recent.iso" = the most recent backup

"debug.iso" = the 2nd most recent backup, which can be used to compare and debug the first should it have problems and we want to know what happened between the two.

"old.iso" = the 3rd most recent backup, which is just a last resort in case the first two images both got hosed and we realized it too late.

I recommend keeping a log of all operations. I've automated my logging, which records each operation with timestamps and descriptions. Without it it's easy to forget what we're doing which might cause heartburn in the event of a problem.

I also manage an image of /boot, "boot.iso" which I have on its own partition. On occasion, /boot or the master boot record gets corrupted, and this has saved my neck.


Again, I've automated this entire process with a single Bash script and it works beautifully every time. It makes using Mint practical because having to re-install every time the system gets hosed is too much work. Even though a rough installation takes 5 minutes, it can take days to fine-tune everything depending on how we want everything configured and how well we've documented our desired tweaks from previous installations.

So in my case, re-installation is impractical. It helps to have a lightning fast machine. I recommend SSD drives and quad-core processors and plenty of RAM.

And true, it does take time and disk space, but unless we're a big organization and need to be ultra-efficient with our server racks or procurements, so what? Space is dirt cheap if we go with platters, and even SSDs have come way down, and it's always worth paying more for high-density drives IMO. I never wait more than ~15-20 minutes for a backup and restores are even faster at ~10-15 minutes. I also backup the images to high-density USB drives ( also well worth the price ), so it's really hard to destroy my system unintentionally. And I do recommend backing up to a drive not normally connected to the machine; an "offline" backup of the plugged-in USB backup, which I do monthly, and I have a script for that too. Actually, it's all one highly structured script, broken into separate files, yet all working together as one, but you don't have to do it that way.

My system is never down for more than 25 minutes unless I want to spend extra time to debug the failure, and therein lies the reward of all this. Since both partitions are setup identically, we can boot into either and run everything like new even if the main one goes down. We'll spend time making backups when we make critical changes to our system that we want to be sure to save, so we don't needlessly and endlessly toil just keeping the system stable and working. These disk dump, backup, and restore operations take time, but actually, while it's doing its thing we can go off and do our thing with no noticeable performance issues, at least with SSD, unless we're already running a ton of disk-intensive processes, and if we are, we could run the script while away or idle. And always avoid reading, and especially writing to, the drive you're making an image of or restoring an image to, which can result in a corrupted image.

Hope this helps.
This setup serves me well!
Before I wrote this script and established these conventions, system maintenance for me was a nightmare!
Now I'm flying!

I'm not sure I'd vote yes even if my system restore paradigm were implemented in a cool, easy to use GUI because I might want to fine-tune the operations or make it do other things, or handle special situations, etc. ( I've built a simple GUI into my script and it works great. I just select the procedure option I want from the menu and it handles everything from there. )

But I do swear by this method.
Thoughts and criticisms welcome!
I'm open to trying the btrfs / snapshot method if Mint 18 adopts it.

[reddot]

See Above

nice tutorial, i use linux mint 17.2 mate for business, i need a setup like yours. i need as little down time as possible.

[linx255]

nice tutorial, i use linux mint 17.2 mate for business, i need a setup like yours. i need as little down time as possible.

Thanks; I've since added instructions for configuring each fstab.

You may use your existing setup and adapt this example to it.
Just create 'backup.sh' and 'restore.sh' scripts somewhere off your main drive; on a USB drive if you must.
You can create launcher icons for them too ( .desktop extension ) which helps.
Do be careful the commands are crafted just right. No typos, and only execute when you're positive it's right.

I mean I'm sure this isn't practical for everyone since Bash scripting and testing is required, but these are simple scripts.
When I started doing this 2 years ago I didn't know squat about Bash; I found all the help I needed on-line.
General programming background helped for making more sophisticated features though.
You may run them past somebody else to make sure you know what you're doing.

I'd take care of all that for you, but not for free.
( And I'm guessing it's against the forum policy to solicit services anyway. )

[linx255]

...Other Ideas...

1) We can also take this a step further and make our own "snapshots" by writing a script to compare .iso images ( using rsync as a 'difference boolean operator' probably ), and extract only those files different in each .iso image and throw them an .iso of their own, per desired version. This way we can potentially keep just one OS .iso and multiple, smaller .iso's that can be used to custom patch an installation freshly written from the main OS .iso, if that makes sense. And it's probably just a page of code in most cases. I haven't attempted this yet, but I'm tempted to, just for the possibility of infinite .iso versions without hogging so much disk space. Then with that setup, in theory, we could drop down a generic OS .iso on the drive, and select a patch .iso from a menu to complete the OS implantation.

2) We can also manipulate .iso images for whatever reason. Let's say you made an image but wanted to make one last change without re-doing the whole image. Simply mount it as read-write, edit, and unmount. This could be useful for when we make frequent and critical changes to the system that we want to preserve in the image files without constantly redoing the image. So long as we're aware of which files we're updating and that there may be changes to certain files on the system that aren't getting updated without conscious effort, it provides a quick solution to keep important changes up-to-date or virtually everything important up-to-date. This would only work with correct rsync and mount settings.

3) In theory ( I don't know how to do this yet ), we can emulate an .iso image for whatever reason. If we don't want to, or can't, back out of our OS and shut down / reboot into another drive to test changes to the file system, we can simulate how a change to the file system will occur with a Linux emulator, of course, assuming the emulator is setup to account for all the things essential to those changes. We can emulate Mint within our Mint environment to test out a version if we need a sandbox, or if we want to emulate our Mint setup from a Windows / Mac PC and decide to retain the changes made to that file system on our Linux PC, we can work on our Windows / Mac PC and when done, implant the altered .iso image to the Linux PC. This may come in handy if you're away from the home or office, have a Windows / Mac PC and your Mint .iso image on a thumb drive, and don't want to SSH into your Linux PC, or aren't setup for SSH-ing, and need to get work done. Again, hypothetically.

4) Of course, we can manage images of Windows and Mac systems using the same methods, whether from LiveCD, or a Linux partition that shares a drive with a Windows or Mac partition. So if your Windows / Mac keeps getting hosed ( which was always my experience when I used Windows and Mac ), then you may simply revert that system to your perfect image that you made the day before, or whenever. Talk about resilience! Of course, I personally view Windows and Mac OS as toys to be emulated and never installed in reality, but there are times when you may be using a work computer or public house computer and you've just had enough of it going haywire. Time to own it with OS image management and rapidly undo any damage from malware or other users installing too many of the wrong things. Just make a clean install once, image it, and you're golden. Never again will Windows / Mac shut you down for more than half an hour and you'll never lose all your configs and stuff. That said, if you happen to be teetering between Windows and Mint on the practicality line, I recommend sticking with Mint because ultimately you may adapt and find you rarely, if ever, need Windows, which you'll simply emulate with VirtualBox if you ever do, and manage VM ( virtual machine ) images similarly to your OS images.

[BluuzMoBeeL]

Save your settings to USB/ File whatever.
So a new install, just load the settings.

I cannot count how many times system restore saved the day and precious time when I did something and just needed to get back to where I was, it just simply saves time if anything goes wrong.

[linx255]

Save your settings to USB/ File whatever.
So a new install, just load the settings.

Yes, and that works sometimes but is not a comprehensive solution because it's not certain just configuration files that enable a functioning system. Your system files or file structure may get hosed and you might not know which ones are causing problems. Might as well copy the whole thing in functioning state if you have the space, time, and have the need to virtually guarantee restoration in virtually any worst case scenario.

I do also manage / backup configuration files a la carte as opposed to the entire OS partitions as wholes, and this is obviously something to try before restoring the entire disk image if you know which files got messed up. However, whatever caused the break might have also broken something else not included in your settings / config file archive and wouldn't necessarily know it / right away. Or you might have missed an essential config file when backing them up, and then you'd have to dig to find it and hope you know how to fix it, find out how to fix it, or have the time to do either.

So I'm just offering a generic, one-size-fits-many ( and-adaptable ), way to retain virtually everything that makes your system function as intended while capping down time to a maximum of 30-60 minutes regardless of the problem(s), so you don't have to deal with config files, tracking system changes, or debugging if you don't have time.

I can't tell you how many times my system has been broken and none of my 100+ config files saved the day. Re-install takes me several days, if not a week, to fully configure Mint; install all the packages I use, configure each package, configure the desktop, arrange the file system, copy config files, test and calibrate devices, etc. ( And I've automated much of that as well if I ever do need to start over, but that's a rare last resort for me. ) And a lot of settings are difficult to find the corresponding config files for. They can be buried in a vast directory, and that's why I manage the whole OS.

The reason I modify Mint so much is to maximize productivity, because out-of-the-box, while great and better than Windows, is not tailored enough to suit my needs, namely those in the productivity department. So if you're like me and mod the toast out of Mint, then re-installing and loading the settings isn't practical. All my Mint tweaks really serve business just by making it easier and faster to use, resistant to time-consuming problems, and shining resilience basically no matter what. The last time I re-installed Mint and painstakingly loaded all my settings, I said to myself, "Never again!"

[rambo919]

Yes it's not a "hardcore" solution but it is one of the best things m$ managed to actually make work.... most of the time.

[linx255]

Oh, ok. I always had to re-install Win; SR was no good for me. But yeah, it must work for some folks.
I'm trying to make my solution as robust, well-rounded, fool-proof, cross-compatible, and user-friendly as possible.
Over the years maybe I'll continue to develop this so it has an easy installer with all the options you need, a nice gui for initializing operations and setting schedules, etc.
Then that would be even more hardcore, but a more attractive solution since you wouldn't have to mess with code, scripts, and what not.

[ChrisK99]

There's already a few native linux apps that do a good job of System Restore: Timeshift and BackInTime are the best of the bunch (IMO)

Both take snaphots that can be restored... Timeshift will also clone your installation to another hard drive, and automatically edits/installs grub and edits fstab (I've a few installs cloned to USB drives that run perfectly on other hardware... ) BackInTime has a similar option to restore to another device, but I'm pretty sure it's a direct clone of the snapshot, so you'd have to reinstall grub etc manually on the target drive

Chris.