[mythtv-users] Disable Automatic Database Backup

[Mark Garland]

Hi Mike, Eloy and Greg,

Thanks for your replies on this.  I am still finding these scripts a little
confusing, so just wanted to clarify a few quick points.  

My distro (Kubuntu) has a script in cron.weekly by Paul Andreassen, although
by default it's backing up to a location on the same disk which could limit
the usefulness of the backup (although, I can easily change this).  

However, I am still confused as to mythfilldatabase.pl.
- should I be running it?  I think so.  I'm sure I read somewhere that it
should be daily.
- and when should I run it, linked to optimize_mythdb.pl (i.e. should it be
done before or after?).  I'm guessing before - so that the database can be
filled, then optimized, then backed up.

My current thinking: (the box is unlikely to be used between 1am and 6am)
- I'll leave the "Disable Automatic Database Backup" setting unchecked
although I now understand that it doesn't do quite what I thought.
- I'll disable the distro provided backup script.
- I'll set mythfilldatabase to be run at, say 1am-2am, through the mythtv
settings menu.
- I'll write a script of my own, to be run daily, *after 2am* that will call
optimize_mythdb.pl, then right after will use the scripts that Mike has
suggested (http://www.mythtv.org/wiki/Database_Backup_and_Restore).  
- I'll set my jobqueue to run 4-6am, ensuring that the backup will be done
long before any jobs start.  If I do it the other way around, and have a
long running job, it could catch out the backup.

Am I close?

Thanks for all your help so far,

MG

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Michael T. Dean
> Sent: 11 November 2009 20:39
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] Disable Automatic Database Backup
> 
> On 11/11/2009 02:25 PM, Eloy Paris wrote:
> > On Tue, Nov 10, 2009 at 08:30:10PM -0500, Michael T. Dean wrote:
> >
> > [...]
> >
> >> Sorry, I haven't gotten that far, yet.  We need a /lot/ more
> >> infrastructure to prevent automatic backups from corrupting the DB
> >> or recordings.  It's on my TODO--just might be below a much bigger
> >> job that will actually make the auto-backups /much/ easier.  :)
> >>
> >
> > Hhmmm. Dumb question: why would a backup corrupt the database or
> > recordings?
> 
> The recordings could easily be corrupted when the system becomes I/O or
> even CPU bound, depending on system resources and capture configuration.
> 
> The database corruption is mainly possible when making Myth perform
> automatic maintenance--which is required to make sure the backups are
> actually useful.  If we tell users we do automatic backups, then when a
> user needs a backup, she finds out that some of the tables were crashed
> when the backup(s) was(were) created, so those tables and their data is
> not in the backup, it's actually worse than telling users to maintain
> and backup their databases themselves.
> 
> For both of these issues, we need an approach to make sure that Myth
> isn't doing anything (recording, playing back, transcoding, commercial
> flagging, ...) at the point when we do the backup.  And, to make things
> work properly, we really need to ensure that no one (/none/ of the
> frontends/backends/other clients (like MythWeb)) is changing the data in
> the database when the backup is created.
> 
> >  I mean, a backup just reads data, right? Or that's not the
> > case here? Is the issue that a backup cannot be made while there are
> > clients (backends, frontends) connected to the database?
> 
> That could easily cause corruption of the data in the backup, itself, so
> another reason we need the infrastructure discussed above.
> 
> FWIW, you should be fine creating a cron job to back up your database
> daily (or whatever).  Just do your best to pick a time when recordings
> are least likely to occur.  If you're running optimize_mythdb.pl in a
> cron job, you may want to just add mythconverg_backup.pl right after
> it.  However, we're currently leaving it up to the user to decide
> whether or not to do so.
> 
> http://www.mythtv.org/wiki/Database_Backup_and_Restore
> 
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users