On Friday, August 8, 2014 6:36:56 AM UTC+10, Daniel Farina wrote: > > Yeah, unfortunately a hopefully-idempotent PUT is rather useful to > deal with the problem of lost responses for successfully processed > PUTs from S3 in event of a network blip. And, I don't think S3 has a > no-overwrite permission level. > > There are ways around such a catastrophic scenario like the S3 > versioning feature, but then WAL-E would have to learn how to address > versions for replay and have deletion semantics (or you'd have to > write some side-bar software to massage the version of things and > produce a prefix for WAL-E to use). >
It looks like the best way to manage an accidental (unlikely) or malicious overwrite of any streamed logs would be to identify the "deleted" objects by: 1. Checking for anything with > 1 version (and because WAL-E does not, and should not, be version aware, this should capture any deleted objects) 2. Retrieving the version with a date prior to the issue occurring (http://docs.aws.amazon.com/AmazonS3/latest/dev/RetMetaOfObjVersion.html) 3. Restoring the selected version - which will have the same key as the original. Because the key and the object has not changed, WAL-E won't know any different - since it only ever operates on the "current" version by virtue of not using the versioning API. This is hopefully something that I won't have to do (ever!) although I'll see if I can give it a test run this weekend by deleting a bunch of streamed logs and then restoring them in-place. -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
