[mythtv] Ticket #4760: Use a script for the database backup

Michael T. Dean mtdean at thirdcontact.com
Sat Mar 8 17:37:14 UTC 2008


On 03/08/2008 05:01 AM, MythTV wrote:

> #4760: Use a script for the database backup
>
>
> Comment(by nigel):
>
>  While using a script is tidier in many ways, I think it should be
>  optional. ''e.g.'' The current code works well for Mac OS X clients, but
>  '''''requiring''''' an installed script to circumvent an accidental
>  upgrade on a random machine is not good.
>  [[BR]]
>  I would recommend ''adding'' !DBUtil::DoBackup(QString, QString), and
>  having DBUtil::BackupDB() decide which one to call.

So, you mean leave the current code in place and add code to run the
backup through a script?  I /really/ liked the the idea of taking the
hard-coded backup process out of the MythTV compiled code...

If your concern is over compatibility (i.e. if MacOS uses a different
shell or something), I've completely rewritten the script to use Perl,
instead (which--I hope--will be more platform-independent).  See below
for more details.  In my plan, the backup script will automatically be
installed to the share dir with a source install, and vendors/packagers
will have an option of replacing/modifying the script as desired (to
account for mysqldump version differences, to use a different
script--such as a mysqlhotcopy or automysqlbackup--or whatever)--or, for
that matter, of just creating a symlink in the bin dir to the backup
script making it available for "manual" backups.  Users will also have
the option of renaming/completely removing the script (to disable
"automatic" backups) or simply setting DatabaseBackupScript to "" in the
DB to prevent automatic backups (though many have requested a new
setting to allow users to disable automatic backups with a single checkbox).

I'm not sure what you mean by "requiring an installed script to
circumvent and accidental upgrade".  If there is no script, the upgrade
is allowed to continue based on the PromptForSchemaUpgrade() code you
wrote.  So, in theory, only people who "disable" the use of
PromptForSchemaUpgrade() will ever accidentally upgrade.  If you mean
that those who do accidentally upgrade and who don't have a backup
script installed won't have a backup (and, therefore, won't be able to
downgrade), that is a downside.  (And, funny you're concerned over a
backup not occurring as most of the feedback I've gotten on the backup
patch has been, "We really need a setting to disable these backups." :)

And, yes, I realize that most users start their backends using a
non-interactive init script or through a ssh session without X
redisplay, both of which may result in disabling the
PromptForSchemaUpgrade().  Since many users also start frontends with
init/login scripts (and since they may see mythfrontend's -u argument
and decide they'll just put that in there--though they should /not/ do
so), and since even with the PromptForSchemaUpgrade(), someone could
choose the wrong button, it's possible we may have accidental upgrades.
However, this brings me to something I was thinking about the other
day.  We currently enable automatic schema upgrades for the backend or
mythtv-setup when we determine the user is running myth* in an
non-interactive shell.  If the idea is to prevent accidental upgrade,
this could easily fail.  If, however, we included a "-u" argument, as in
mythfrontend, then the user can choose to put it in start scripts (and
bear all responsibility for accidental upgrades) rather than our
assuming they want to upgrade since the shell is non-interactive.
Thoughts?  (Not asking you to patch it, I will if the devs are OK with
the idea.)

Anyway, changes to the automatic backup are definitely not required for
0.21 release since on most users' machines, the automatic backup in 0.21
will occur a grand total of one time (since it occurs only on
DBSchemaUpgrade).  They won't even come to rely on it, so a hard-coded
approach that may fail is not that big an issue.  For 0.22, though, I
plan to have a full automatic backup solution available, and would love
to get rid of the direct calls to mysqldump and gzip (which could be any
random program).

Thanks for the feedback, and please let me know if I've misinterpreted
your comments.

Mike ("Does this guy have a --q switch?") Dean

BTW, you can find a copy of the current backup script at
http://misc.thirdcontact.com/MythTV/database_mythconverg_backup.pl
in case you (or anyone else, for that matter) would like to test/run
it. IMHO, it's actually ready for production use--even for 0.20 or
0.21 users. (Bug reports--direct to me--appreciated. ;)

You don't need to apply the patches in #4760 (which would require
modifying the extension on the default for DatabaseBackupScript or
modifying its value in the DB/through command-line overrides).  Instead,
just run the script from the command line.  I designed it to allow users
to run it whenever they want (manually or from an init script or a cron
job).  It will take a database information file (as provided by the
backend in the #4760 patch), command-line arguments, or even read
"defaults" from a $MYTHCONFDIR/backuprc (i.e. ~/.mythtv/backuprc) file.
Use database_mythconverg_backup.pl --help to get details.  When testing
it the first time, run it with the --debug (or --verbose) argument to
see what's happening.  In addition to being very good at determine
configuration, it supports compression (if IO::Compress::Gzip is
installed, it uses that--but doesn't require the lib--so it doesn't even
have to be able to find gzip, and it will fall back to gzip if it the
IO::Compress::Gzip lib isn't available).  And, more importantly, it
supports backup rotation (by default, keeps the last 5 backups, but this
number is configurable--on my system, with 442 MPEG-2 recordings, a
gzip'ed backup is about 30MB, so 5 take up only 150MB).

I'll be posting the updated patch/scripts to #4760 soon.  I just have to
finish the restore script (which is a lot more annoying to test than was
the backup script).



More information about the mythtv-dev mailing list