cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <>
Subject Re: Backup/Restore: Coordinating Cassandra Nodetool Snapshots with Amazon EBS Snapshots?
Date Thu, 23 Jun 2011 14:30:04 GMT
> EBS volume atomicity is good. We've had tons of experience since EBS came
> out almost 4 years ago,  to back all kinds of things, including large DBs.
> One important thing to have in mind though, is that EBS snapshots are done
> at the block level, not at the filesystem level. So depending on the
> filesystem you have on top of the drives you might need to tell the
> filesystem to "make sure this is consistent or recoverable now". For
> example, if you use the log-based XFS, you might need to do xfs_freeze,
> snapshot disc/s, xfs_unfreeze. To make sure that the restored filesystem
> data (and not only the low level disk blocks) is recoverable when you
> restore them.

No. That is only require if you're doing multi-volume EBS snapshots
(e.g. XFS on LVM). The entire point of an atomic snapshot is that
atomicity gives a consistent snapshot; a modern file system which is
already crash-consistent will be consistent in an atomic snapshot
without additional action taken.

That said, of course exercising those code paths regularly, rather
than just on crashes, may mean that you have an elevated chance of
triggering a bug that you would normally see very rarely. In that way,
xfs_freeze might actually help probabilistically; however strictly
speaking, discounting bugs, a crash-consistent fs will be "consistent
snapshot consistent" as well (it is logically implied).

But this all assumes the entire stack is correct, and that e.g. an
fsync() propagates correctly (i.e., not eaten by some LVM or mount
option to the fs) in order to bring that consistency up to the
application level.

/ Peter Schuller

View raw message