On 6/10/2012 22:26, Karl Denninger wrote:
Well, backup with snapshots don't do well EITHER on a database unless you can snapshot BOTH the dbms data store(s) and the transaction log store(s) /*at the exact same instant*/. If you cannot then you're asking for trouble and are likely to get it. But I've dealt with that particular "gotcha" problem in a different way for the DBMS I use (Postgresql)
You asked what would happen, not what was the best way to back up a SQL DB, but your point is valid.
Snapshots don't fix this issue entirely but drastically reduce the chance of a 100% broken backup.
SQL servers should be dumped out to disk (ie; mysql_dump) to avoid this or have a dedicated backup client (which means you're probably not using dump anyway).
So basically what you're saying is that SU+J leaves you exposed to having no real backup option that provides a rational guarantee of the ability to restore the backup taken.
That's a bit of a gloss over on what I said. My point was that you might end up missing something if its changing at the time the backup was taken. It really depends on what specifically that server is doing.
There is also a consistency issue too, using snapshots makes it so that all the files make sense together, instead of the files getting more and more recent as the end of the backup block approaches.
-- Adam Strohl http://www.ateamsystems.com/ _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
