[mythtv-users] Restore backup?

[Michael T. Dean]

On 01/06/2014 04:19 PM, Jay Ashworth wrote:
> From: "Michael T. Dean"
>> Definitely. You can't just rip the database out from under the MythTV
>> system and expect it to handle things properly. You should shut down
>> /all/ MythTV applications on /all/ hosts when doing a restore.
> On the other side: how does *making* the backup interact with the BE
> and FE being running?  Since I gather I'm worng, and the default table
> type is MyISAM, then --one-transaction is certainly not going to help
> anyway; will there be interactions between making the dump and running
> the BE?  Will backups be incoherent?  Could a running backup freeze up
> the UI on the FE?  And what about Naomi?

Because mysqldump locks tables as it backs them up, it's possible that 
backing up the database while MythTV applications are running will cause 
issues, such as UI lockups (or worse, possibly up to and including 
crashes due to inability to get data it needs), purely dependent on 
timing of both the table locks (which tables are locked when and for how 
long) and data reads (which are dependent on what, exactly, MythTV 
applications are doing).

Also, creating a backup while systems are running and, potentially, 
changing data may result in data corruption due to the fact that 
different tables are being dumped at different times.  Though 
--single-transaction wouldn't work with MyISAM tables, --lock-all-tables 
would effectively do the same, but would make things even worse for 
running MythTV applications being able to read/write data because the 
lock would persist so long.

Therefore, the recommendation is to do backups when no MythTV 
applications are running/connected to the database.  This approach 
solves both of the above problems (and does so without a need for 
--lock-all-tables).  However, one may choose to do backups on a "live, 
but as-idle-as-possible system" and risk some data corruption.  
Generally, this shouldn't be a problem, especially since it's likely to 
be a small amount of data that's corrupted, and likely only data for 
recent, in-use recordings, as most of the non-recording data tends to be 
rather static or temporary, and even recording data stays basically 
static once recording and jobs are complete.

So, choosing to run a backup at a time when MythTV is unlikely to be 
busy (recording, transcoding, detecting commercials, ...) every once in 
a while and doing a "safe" backup occasionally to complement it may be 
enough for most, depending on how much they value the data.

I tend to be in the "it's just TV" camp and do occasional backups (but 
not even on a cron job), happy with the knowledge that if I lost my 
database, I could put any recordings into Video Library and still watch 
everything.  However, before any MythTV upgrade, I /always/ do a manual 
database backup safely, with all MythTV applications shut down.  I'm 
willing to lose a database due to some kind of system failure, but not 
due to my failing to take appropriate precautions before an upgrade. :)

Oh, and I do /not/ recommend this lackadaisical approach to anyone 
else.  Everyone else should take all suitable precautions to protect 
their MythTV databases (to such level as they deem appropriate based 
upon their own valuation of the data).

Mike