rich z's picture

I setup a LAMP instance with daily backups.    Yesterday I installed some PEAR modules and then decided I didnt really want them.  I did a restore to a version before PEAR was installed and to my suprise the module still fired up on the next reboot.  Is this user error on my part(I assume) or is there some design reason as to why this module was survive the restore?

Details -

After deciding to rollback I  went to TURNKEY HUB found the backup from the day before. (At the time it was the last backup) so I ran this command line.

tklbam-restore 2

Everything looked okay before I restarted the instance.  It did tell me the restore was done.   After the reboot I  went to command line and typed PEAR and I was dumbfounded to find that it responded.   I thought maybe this backup was taken after I installed PEAR so I went back one more day

tklbam-restore 2 --time 2011-11-01T06:25:21

Same thing.. PEAR responded after the reboot.

I am assuming this is operator error on my part, just not sure where.  Is it correct to assume that if I were to rollback to before a module was installed that module would be removed from the system?

Jeremy Davis's picture

So restores will restore config files to their previous state (by overwriting them with the older versions), but won't actually remove additional items that have been installed and/or configured since. So it will only add and overwrite. AFAIK MySQL tables are the exception to that rule as I'm pretty sure that the whole DB is dumped and then when restored overwites everything (I think anyway - I haven't tested that).

So if you want a clean install with just whats in your backup you'll need to restore your TKLBAM backup to a clean instance.

rich z's picture

ok great.. at least I wasnt going crazy...  I would have thought even if the PEAR files where left, the config to start them would rolled back.. but regardless if it is a add/overwrite restore rather then a snapshot restore I agree it makes sense to go to a new instance to not leave file turds all over the place.

I am using a VM on my own server while in project dev stage.  Is there a way inside Linux to allow me to wipe the drive and then take the restore?   If not I assume this is the fastest way to get back in business?
1)Shut down VM
2)Unzip the VM file drive files back to the folder that stores the drive files for that VM
3)Start  VM and complete initial setup
5) run following command

tklbam-restore 2 --time 2011-11-01T06:25:21

Thanks for all your help....

Jeremy Davis's picture

Even though it's probably not a big deal, may as well keep it as clean as possible. And if you do it now, you avoid those files becoming part of your backups.

I have only had a minor tinker with the VM images (I use ProxmoxVE and most of my servers run under OVZ or I install to KVM from ISO) but your steps look reasonable to me. Good luck with it.

rich z's picture

Should I enable the automatic updates when I first install the image?

I guess is all comes down to how the updates are stored and tracked and are the updates that installed at startup the same type that get installed during nightly patch checks?

If I say 'yes' to the udpate - One thought was if there were new updates since my last backup  what would happen.  If I then did my restore would the get wiped out but then reapplied later?

If I say 'no' to the udpate - Will the restore turn on automatic updating?  will all the packages that get updated on start-up still get updated at some point after I do the restore?  If I restored back to a version from two months ago can I force the system to do an update?

Jeremy Davis's picture

If the security updates aren't installed at boot, they will be auto installed within 24 hrs (usually around 4am). So yes they are the same  updates.

Any packages that are default packages (ie get security updates on install) won't be included in TKLBAM backups anyway. TKLBAM only backs up extra packages.

Another thing, TKLBAM by default can only install packages that are in the repos. Unless pinned, packages installed from repos will always be updated to the latest (available) version if you install them, so TKLBAM can never overwrite installed packages like that. It is a very cool feature of how package management is handled in TKL/Ubuntu/Debian.

Add new comment