Marcus's picture

I had an issue earlier today where my WP instance got hacked, so I tried restoring to an earlier backup with TKLBAM and I see that the infected files are still there.

I also tried deleting the entire folder, and restoring the latest full backup, but all of the files weren't brought back so i was stuck with a half-installation of WP.

Downloading the latest WP source and installing that thankfully brought everything back to normal, but this now presents a problem because I was depending on TKLBAM more than I should have it seems and I'm somewhat disappointed by the whole experience.

Can you give any insight as to what happened here - 

How come files aren't deleted when reverting to an older backup?

Also, why certain files aren't restored from a previous backup?

Forum: 
Jeremy Davis's picture

As such it only saves/restores specific files/folders. This is what makes the backups so small, relatively fast and allows the use of TKLBAM as a migration tool between various (different) versions of TKL. To make it work in the way you expected would break it for other (legitimate) usage scenarios.

IIRC you can see what files/folders TKLBAM is saving by running a simulation (either run from the Webmin module or see the docs for details). You can also explicitly include or exclude particular files as you desire.

Generally though if you only edit/add files in places where TKLBAM expects you to, all should work as planned. If you start playing with files in 'naughty places' then TKLBAM will not back them up by default, and although you can override it (ie make it back up the 'naughty places') you risk other issues by editing/backing up/restoring files in these places (hence why they are considered 'naughty'). Having said that it is possible that the devs have overlooked something and a location that ideally should be saved has been missed.

So long and the short of it is if your server has been conpromised, best practice is to launch a fresh TKL instance (of the same type as your backup relates to) and restore your backup to that.

Although best practice would also mean that you are continuously checking that your backups work as planned by testing them regularly (in a fresh instance). It doesn't matter how often you do backups, if you aren't sure that they will work when you need them, what's the point?! Restoring backups to a fresh AWS instance is fantastic for testing as it is fast and will cost you very little (literally cents...).

Marcus's picture

Yes, i have previously used tklbam for restoring to a new instance, that did work as expected, but in this case I wanted to avoid that as I'm pretty sure how the hack happened (older WP version/plugin, known loophole)

The files were located in the default /var/www/wordpress folder.

thanks for explaining, next time (hopefully not due to a hack!) I'll just make a new server instead.

Jeremy Davis's picture

I haven't tested it myself, but theoretically if you script your upgrade you could include that in your restore as a pre-restore hook. Have a read here.

Add new comment