UpdraftPlus Home › Forums › Paid support forum – UpdraftPlus backup plugin › Amazon S3 Versioning & Lifecycles
- This topic has 5 replies, 2 voices, and was last updated 10 years, 5 months ago by Andrew.
-
AuthorPosts
-
May 31, 2014 at 7:44 pm #18080AndrewParticipant
I’m working on setting up S3 backups as securely as possible. I’m following this post:
https://updraftplus.com/faqs/what-settings-should-i-use-for-amazon-s3-and-how-should-i-configure-my-amazon-s3-account/But the “Lifecycle Rules” setup page at Amazon has changed since you posted it..
My goal is simply to have nightly Updraft backups stored in the standard S3 class for 8 days, and then have them archived to Glacier storage for 60 days, and then deleted. It seems unnecessary to enable Versioning as I think the Lifecycle Rules themselves can handle this, and Updraft’s filenames are unique to each backup (right?).
Right now i have it set with versioning off – and the lifecycle rules as follows:
Action on Current Version (Archive & Then Expire):
Archive to the Glacier Storage Class 8 days after the object’s creation date.
Permanently Delete 60 days after the object’s creation date
Action on Previous Versions (Do Nothing).Is this all I need?
May 31, 2014 at 10:00 pm #18799udadminKeymasterHi Andrew,
The reason for the ‘versioning’ advice on that page is not to do with Glacier, or automatic deletion, but for extra security. The relevant bit is the first paragraph under the heading “What is the most secure possible setup?”. Theoretically, a hacker who hacks your WordPress website can then access the S3 key stored in its database, and could use that to make calls out to S3 to permanently delete all your backups. S3’s versioning prevents that.
Your scheme will work, as long as you’re not bothered about that particular protection. Note that if you’re getting S3 to do the deleting for you, then you’ll want to not have UpdraftPlus itself do any – so turn the ‘retain’ setting up to some ridiculously high that will never happen (e.g. 99999 days).
Best wishes,
DavidMay 31, 2014 at 10:01 pm #18800udadminKeymasterP.S.
Quote:Note that if you’re getting S3 to do the deleting for you, then you’ll want to not have UpdraftPlus itself do any – so turn the ‘retain’ setting up to some ridiculously high that will never happen (e.g. 99999 days).The retain setting in the UpdraftPlus configuration page, that is.
David
June 1, 2014 at 4:11 pm #18801AndrewParticipantHi David,
I did indeed set up the AWS User Policy so that UpDraft can’t delete the backups – so wouldn’t that still be “the most secure possible setup”?
Why do we need versioning in addition to lifecycle rules?
Versioning seems to be used for filenames with the same name.. but UpDraft uses unique filenames for each backup. So the lifecycle rules should be sufficient to delete old backups after X number of days (and to move them to Glacier storage as well).
Note the third rule I listed above: “Permanently Delete 60 days after the object’s creation date”..
Perhaps to make my question clearer, here’s a screenshot of what I’m doing — with lifecycle rules in place, but versioning not turned on. Shouldn’t this be sufficient, as long as the user policy doesn’t allow deletion?
Thanks,
AndrewJune 2, 2014 at 7:49 am #18802udadminKeymasterHi Andrew,
Quote:I did indeed set up the AWS User Policy so that UpDraft can’t delete the backups – so wouldn’t that still be “the most secure possible setup”?No – because the theoretical hacker can, instead of performing a delete operation, instead over-write (with junk data). As the article says: “Its ability to write, however, still means that it can overwrite existing backups, which is effectively a way of deleting them, as well as tampering with them.”
David
June 3, 2014 at 3:55 am #18806AndrewParticipantAh, that makes sense… I should have read more carefully! <hangs head in shame>…
Headed over to switch on versioning now!
Thanks again,
Andrew -
AuthorPosts
- The topic ‘Amazon S3 Versioning & Lifecycles’ is closed to new replies.