On Thu, Aug 7, 2014 at 3:43 PM, Matt Silverlock <[email protected]> wrote: > 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)
Careful with relying too hard on exactly one version. A dropped response (successful S3 commit, but for any reason WAL-E was not able to exit with an exit code to tell Postgres of that fact) will trigger a retry, and then I think that'll make two versions. > 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 could also maybe make WAL-E GET requests version aware if you find a pattern that works and it's not too tortuous on the current code. It may be easier than writing a different tool. Tentatively, I am not opposed to carrying that feature patch if it didn't get too complicated unless you think there are reasons why I shouldn't. You might find the blackbox integration tests (see test_blackbox.py) a quick way to iterate on it, also. Plus, I would like those tests if I carry the patch :) -- 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.
