BALUG backup of mysql database for transfer ...
So, BALUG has some old content in mysql database (PostNuke - MySQL + PHP) hosted on DreamHost, and we're moving away from DreamHost hosting.
So, recommendations on best ways to save any and all of that mysql data content, for later examination/restoration/extraction, etc.? Not that we're planning to ever, at least "permanently" run PostNuke again, but on our "todo" list includes archive preservation/restoration, and that would be one of those pieces (does hold a fair chunk of older BALUG history - some years of wiki/forum/blog type stuff in addition to web content).
So far, I've basically done:
$ (umask 077 && mysqldump --all-databases --host HOST --user USER --password > mysqldump.out 2>mysqldump.err) $ (umask 077 && mysqldump --skip-opt --all-databases --host HOST --user USER --password > mysqldump--skip-opt.out 2>mysqldump.err)
Each time, above, no error output (just an empty resultant mysqldump.err file). And the files / amount of data isn't very large at all:
$ ls -onstr *.out 1532 -rw------- 1 1690893 1566321 Mar 9 05:39 mysqldump.out 2492 -rw------- 1 1690893 2547875 Mar 9 05:46 mysqldump--skip-opt.out $
So, ... thoughts/comments/suggestions/recommendations on manner of saving that mysql data - at least in some reasonable form we may hope to do something useful with it in future? (most notably at some point restore enough of it to extract and preserve the PostNuke content)
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
BALUG backup of mysql database for transfer ...
So, BALUG has some old content in mysql database (PostNuke - MySQL + PHP) hosted on DreamHost, and we're moving away from DreamHost hosting.
So, recommendations on best ways to save any and all of that mysql data content, for later examination/restoration/extraction, etc.?
Your existing solution is, AFAIK, the best possible. mysqldump output is a raw *.sql file that, if executed, zeroes out a mysql tablespace, makes the necessary table from scratch, and then runs INSERT commands to build back the contents to exactly the state they were in at the moment of dump.
Of course, your backup doesn't separate out the PostNuke data from the wiki, forum, blog, Web, and whatever-else-there-is other bits -- but is that necesary? If someone ever decides to revive PostNuke, load the dump file, examine tables to decide what tablespaces PostNuke does _not_ need, DROP those, and you're done. Meanwhile, diskspace for backups is cheap.
Same procedure applies if someone decides to revive the wiki/forum/blog type stuff, etc.
(The quick & dirty implementation you actually do beats the perfect one you swear you'll complete any day now. Or, to put it another way, 'good enough' is your friend.)
It's possible there's some complication I'm missing. (A week of the flu will do that. ;-> )