How The Backup Process Has Changed [LWN.net]

How The Backup Process Has Changed

Posted Nov 29, 2007 4:44 UTC (Thu) by njs (subscriber, #40338)
In reply to: How The Backup Process Has Changed by brouhaha
Parent article: How The Backup Process Has Changed

>Applications that are interested (e.g., MySQL, Postgres, etc.) would listen for those, and
send back a response that they are getting ready, and another when they are done.

So, I was thinking about this, and I can't actually figure out why an app like MySQL or
Postgres would care about whether a snapshot was pending.  Unless you have MySQL's famous
I-don't-care-about-my-data mode turned on, in these systems all committed transactions are
already on disk (and will be included in the snapshot), and all uncommitted transactions are
not (and will not be included in the snapshot).  And the RDBMS has no say in which
transactions are committed and which are not.  So... what would they actually do if they did
receive this message?

(And more disturbingly, what does MSSQL think it has to do?)

(Log in to post comments)

How The Backup Process Has Changed

Posted Nov 29, 2007 10:20 UTC (Thu) by james (subscriber, #1325) [Link]

Put it another way -- a database that cannot be restored reliably from a point-in-time snapshot cannot be restored reliably if the system crashes.

This may be acceptable if there is a suitably reliable way of recreating the state of a database from external data. Usually there isn't.

See also crash-only software: if it's worth putting data into a database, it's worth being sure that the database is really crash-proof.

How The Backup Process Has Changed

Posted Dec 1, 2007 8:31 UTC (Sat) by alankila (subscriber, #47141) [Link]

I second this. As long as the database performs its datastructure updates through journalled
techniques, it should not matter when you take the snapshot.

Maybe MSSQL isn't using proper journalling at interests of higher performance? Journals tend
to incur the cost of having to write the same data twice, once to journal and once to final
destination.

Of course, I should investigate instead of just spouting off, but I'm hoping someone can tell
me what's wrong with this picture, if anything.

How The Backup Process Has Changed

Posted Dec 1, 2007 8:50 UTC (Sat) by brouhaha (subscriber, #1698) [Link]

Sorry, I chose my examples poorly. You're correct that MySQL does not need anything special to force on-disk consistency.

A better example would have been a more typical application such as a word processor or CAD program. If the disk snapshot were to be taken while the application were in the middle of writing a document to disk, the snapshot might not have a coherent version of that document. Of course, this depends a lot on exactly what kind of document writing strategy the application uses. If the application writes to a new file, then moves it to the original name, the snapshot will be guaranteed to have a coherent version of the original file, the new file, or possibly both. Applications that rewrite an existing file are problematic.

How The Backup Process Has Changed

Posted Dec 1, 2007 20:41 UTC (Sat) by njs (subscriber, #40338) [Link]

That might explain why Windows needs this -- on unix, the atomic saving process you describe
is pretty common (is it ubiquitous?  I know emacs uses it, but no idea about, say,
openoffice).  On Windows, though, IIRC, the filesystem semantics are such that atomically
saving a file is impossible.