[wplug-internet] Backup script

[Michael Semcheski]

Hi Vance,

I appreciate the effort you put into this, so here is my rebuttal...

Things that duplicity can do that your method can not:
1.) Restore to a point in time.  "Give me the state of the VPS as it
was on mm/dd/yyyy."

On Fri, Dec 18, 2009 at 9:11 AM, Vance Kochenderfer <vkochend at nyx.net> wrote:
> 1. It preserves hard links; duplicity does not.

This is a fair point.  I do not see this as a particularly important
feature, though.


> 2. It accounts for files (such as MySQL database files) that may
>   be open and in an inconsistent state.  It briefly shuts down
>   the services using those files to get a consistent snapshot,
>   then restarts them for minimal downtime.

Using this method (as part of a cron job, run before duplicity) you
don't have to shut down mysql.

http://www.wplug.org/wiki/Simple_MediaWiki_Backup


> 3. It uses tools that are part of the base distribution....
> I don't know if there are any compatibility problems between
> versions.

This is true, but it seems like in a worst case compatibility problem,
we could always make sure to use the same version that was last used.

(The only thing duplicity needs on the target machine is ssh.)


> 4. It doesn't store history, just a current snapshot, so the
>   amount of disk space used on the target is relatively constant.
>   Alternatives which store historical and incremental backups
>   will continue to grow and consume more space over time.

This is true, but by storing incremental backups you get the ability
to go back to a point in time.

This is especially critical if something gets corrupted, but we don't
realize it for a few days.  You don't want the corrupted data to
overwrite the only copy of the backup available.

And using duplicity won't increase the amount of used storage
indefinitely, it is just a matter of tweaking the frequency of the
full backups to get things the way we want.


> 5. Things are slightly simpler as viewed from the target machine.
>   There is only a single image file.  Duplicity and other backup
>   solutions generate multiple files - if the target owner wants
>   to free up disk space, it's not clear which ones he can safely
>   delete without ruining the backup's integrity.

If the target owner wants to free up space on either method, the only
way to do it is to delete the entire backup set.

Also, all the files on the target can go into one directory.  So if
the abundance of extra backup files is a problem, just don't look in
that directory.


> 6. It is easier on the target's bandwidth as well - when the
>   script is run, it looks at all the configured targets, then
>   chooses the one which is reachable over the network that has
>   the oldest existing backup.  This effectively backs up to
>   targets in a round-robin fashion rather than using them all
>   every time the script runs.

We could incorporate something like this into the duplicity script if
it was necessary.

As these things go, the bandwidth required for an incremental backup
is pretty small.