> 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
