On 17 September 2014 08:25, Gareth France <[email protected]> wrote: > Sounds great. My backups are stored on a hard drive here so can't be > compromised but I'd love to find a way to automate it. I'll look into this > later.
I think the point that Colin is trying to convey is that version-control is NOT a backup strategy. version-control sits BEFORE the deployment to the live site and stores every change made to every file in the site to create a canonical "golden master" history. You then mint your live site as a copy of the version-controlled files. This will then allow you to immediately determine whether files have been modified since deployment, which files they are, and how they're modified. With a backup you are reliant on schedule and spotting the problem before it makes its way into your entire history of backups (unless you keep backups till the end of time). With a backup you also need to restore each archive in-turn until you find one that doesn't have the offending code. This is time-consuming! And you have already highlighted the problem of backups not accounting for changes made since the backup was taken. VCS solves that. Version control allows you to immediately isolate the offending code and excise it by either rolling-back the commit that added it (in the case your vcs was hacked in addition to your live site) or just re-deploying your latest golden master over-the-top of the current infected live site (in the case your VCS is still secure). -- Daniel Llewellyn -- [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-uk https://wiki.ubuntu.com/UKTeam/
