support quality (Re: dump | restore fails: unknown tape headertype 1853384566)

[Karl Denninger]

Peter Schuller wrote:
>> The issue with backing up a database live comes in when the filesystem 
>> where the database and transaction log files are DIFFERS.  You can get 
>> into a pathological case in that instance.
>>
>> If the transaction log and database itself are both on the same 
>> snapshotted entity (that is, the snapshot is pulled at the same instant 
>> in time for both) what you get BETTER be restorable or your database's 
>> transaction log facility doesn't really do what it promises to do!
>>     
>
> Absolutely. Doing things like snapshot based backups of databases
> assumes you know what you're doing since it is not something which is
> documented as an official procedure in your typical database
> administrator guide.
>
> Personally, while I would use such schemes, I would always use a plain
> fully supported regular dump as a fallback position. I would only rely
> on snapshot based processes to do fancy stuff (such as near-realtime
> hot standby with zfs snaps + serialized incrementals).
>   
To add to this what SHOULD (ha!) work is to dump the database partition 
FIRST and THEN dump the Transaction Log partition.

If you do it in the other order you WILL get screwed, as you will have 
transactions committed in the database that are not in the XLOG.  That 
is essentially guaranteed to blow up in your face.

As always any backup scheme has to be TESTED so you can prove to your 
own satisfaction that it is RESTORABLE.  I can't tell you how many 
business clients I have run into (and not only on Unix machines) that 
have wind up with lots of backups and NONE of them can be restored - 
because they never TESTED their backup strategy.

-- 
--
Karl Denninger
karl at denninger.net