[wp-hackers] Incremental backup and restore

[Scott Merrill]

Owen Winkler joked:
> That's my thought.  Now skippy will probably make changes to the
> plugin.  ;)

Not any time soon.

> Chetan Kunte wrote:
>> In a layman's terms, I was thinking of an idea: how about if the
>> database can be backed-up and restored incrementally like "per year"
>> or "per number of posts" in addition to the default option of a full
>> backup and restore. I seriously think the "per year" or "per number of
>> posts" concept is a good idea (provided of course the core contents of
>> a database are not modified in between versions. Do you think I'm
>> totally off?
> 
> The database backup utility is provided as a very simple method for
> users without command-line experience to create backups of their
> databases.  Anything more complex than "Push this button to backup these
> tables" should probably be addressed with a more advanced backup solution.

Absolutely.  The backup plugin is a convenience for people who need to
backup, but are intimidated (or confused) by phpMyAdmin.  It's an effort
to easily give people peace of mind in the event that their site blows
up / gets hacked / falls into a space-time rift.

For a long time I've silently wished that someone would step up and
write the corresponding "Restore" plugin.  That's not something I'm
going to do, and it's increasingly obvious that no one else is going to
do it either.

That's not a big deal, though: you should only need to restore your
database once, when you're recovering from a disaster.  In this
scenario, I see nothing wrong with following Podz's excellent instructions:
   http://www.tamba2.org.uk/wordpress/restore/

> When something goes wrong, blow away the WordPress tables then grab the
> latest backup from Gmail and pump it through phpMyAdmin.  You're back
> online with minimal fuss.  Better yet, if the latest backup exhibits the
> same issues, you've likely got daily backups available going back to a
> time when things were still working.  And you don't have to worry about
> duplicate keys, since every backup is a complete backup.

Actually, the problem with big backups is that the _restore_ caps the
size of the import, either because of phpMyAdmin, or PHP upload filesize
limits, or simple browser timeouts.  But, as you note, if you've got a
gigantic site, you likely have a reasonable account with your reasonable
hosting provider, and other tools are available to you.

I suppose a one-file-per-table export might be a good idea, to alleviate
the need to manually split the backup into separate files in order to
load them one at a time into phpMyAdmin -- but then, where do we stop?
It'll only be a matter of time before someone wants X number of rows per
backup file because they have a ginormous database.

In the end, I think the backup plugin is good as it is.  It's easy to
use, and does what it was designed to do.  Restoration is a different beast.

-- 
skippy at skippy.net | http://skippy.net/

gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49  3544 476A 7DEC 9CFA 4B35