[mythtv-users] Additional Storage
jedi at mishnet.org
jedi at mishnet.org
Tue Nov 27 17:56:15 UTC 2007
> jedi at mishnet.org wrote:
>>> Jay R. Ashworth wrote:
>>>> There is one reason why that's not the same (and not quite as good) as
>>>> merely copying the dump file...
>>>> If you copy the dump file, you only have to lock the whole database
>>>> *once*, and all your backup files are exactly the same. This can be
>> OTOH, doing a remote dump only requires the same network
>> access that MythTV itself does. You don't have to setup
>> anything extra. You don't worry about how you are going to
>> get the other exact copy to the separate machine.
>> For this application, locking the database more than once is
>> a relatively minor issue. It's a very small, low transaction
>> volume database.
> The point is that you can end up with two (or more) not-quite-identical
> dumps if any activity happens between them. That means you can end up with
So? It's a logical backup. Data loss is inevitable and the question
of how much or how little is pretty academic.
> potential problems if all hell breaks loose just after that point and you
> to rebuild.
Not really. Either the backup will yield you a consistent database
that opens or it wont. Whether or not you take multiple exports in a day
from multiple client locations doesn't really matter.
Although it does make it more likely that you will have at least
one good copy to restore from.
It's far more important to save a few backups spanning over some
days rather than fixating on minutia. Proper backup testing is probably
a bit much for an embedded database but that's a good idea too.
> The safest, and easiest course, is to do what I do - but didn't explicitly
Safest? You're just being silly.
> in my previous post - dump the db to the backend *once*, then copy the
> dump file
> off to at least two other servers (I also nightly back up to tape).
> Mike Perkins
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users