[mythtv-users] Restore backup?
Michael T. Dean
mtdean at thirdcontact.com
Tue Jan 7 03:29:50 UTC 2014
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
More information about the mythtv-users
mailing list