Amazon S3 & BackupBuddy: guide to WordPress backups

Here's a guide to using the BackupBuddy plugin to back up a WordPress site to Amazon S3. The video only shows how to do the Amazon S3 initial configuration and user configuration, and adding Amazon S3 as a remote destination in BackupBuddy. The text below the video provides more details about configuring BackupBuddy in general.

Note: for simplicity, this video and post show how to use the Amazon S3 Policy Template Amazon S3 Full Access. However, you should really use a more limited policy for security's sake. I don't have specific steps, but check out Writing IAM Policies: How to grant access to an Amazon S3 bucket for pointers. If you have anything you'd like to share about this, please leave a comment.

Note: This page contains affiliate links. Please see Affiliate Disclosure.

Amazon S3 initial configuration (once)

These are the steps to create and configure your Amazon S3 account. You only need to do this once.

  1. Create an Amazon S3 account. If you already have an Amazon account, log in with that. We use an Amazon account tied to a business email address, rather than one tied to a personal email address.
  2. Sign into AWS Identity and Access Management. For security, you should log into IAM with user credentials, not root credentials.
  3. Create a group (per Amazon best practices). I named mine BackupBuddy. Select the Policy Template Amazon S3 Full Access.

Amazon S3 user configuration (each site)

These are the steps to create an Amazon S3 user. You need to do this for each site.

  1. Sign into AWS Identity and Access Management.
  2. In the console menu, click Users.
  3. Click Create New Users.
  4. Enter user name. We use the domain name (minus extension). So, for, we use optimwise.
  5. Click Create.
  6. Click Show User Security Credentials. Copy the credentials to a secure, temporary place.
  7. Click Close Window twice.
  8. In the list of users, check the box for the new user. Below, on the Groups tab, click Add User to Groups. Select BackupBuddy, then click Add to Groups.

BackupBuddy configuration (each site)

These are the steps to configure BackupBuddy. You need to do this for each site. We're assuming you've already installed and activated BackupBuddy. These are the steps we perform, but you may need to customize the process.

If you have another backup plugin installed, download a complete backup. Then, uninstall the plugin and delete its backup folders.

  1. WordPress admin menu > BackupBuddy > Settings.
    1. General tab.
      1. Set and record ImportBuddy password. We record it in a password manager.
      2. Set Send notification if no completed backups in X days to 8.
      3. Set Error notification recipient(s).
      4. Set Email return address.
      5. Set Maximum number of local backups to keep to 6.
      6. Database Defaults
        1. Select All tables in database.
        2. Exclude unnecessary tables (such as Relevanssi logs and Redirection logs).
      7. File & Directory Defaults: exclude unnecessary files and directories (such as /wp-content/cache/ and themes that can be easily replaced).
    2. Advanced Settings/Troubleshooting tab
      1. Uncheck Enable backup reminders for edits.
  2. WordPress admin menu > BackupBuddy > Remote Destinations
    1. Click Add NewAmazon S3.
    2. AWS access key and AWS secret key: enter values generated for user in Amazon IAM (see instructions above).
    3. Bucket name: a name that's globally unique within Amazon S3. We prepend ours with ow for OptimWise, then add the user name we created earlier. So, for, we use ow-optimwise.
      1. Note: in a previous version of this post (and in the video), we used ow_optimwise. Later, this stopped working due to the underscore, so we switched to hyphens (e.g., ow-optimwise). See Amazon S3 Bucket Restrictions and Limitations.
    4. Remote archive limit: 6. Note that this limit is for the total archives on S3; not per scheduled backup.
    5. Click Test Settings. When it succeeds, click Add Destination.
  3. WordPress admin menu > BackupBuddy > Backup.
    1. Check Send to remote destination as part of backup process and select Amazon S3, then click Complete Backup.
  4. WordPress admin menu > BackupBuddy > Scheduling.
    1. Choose schedule based on how often site content changes. If content changes daily, schedule database backup daily and complete backup weekly. If content changes weekly or less frequently, schedule database backup weekly and complete backup twice monthly. Or, you could use just one schedule: a complete backup weekly.
    2. Database (if site is updated more than monthly; otherwise, skip)
      1. Schedule name: Database
      2. Backup profile: Database Only
      3. Backup interval: Weekly (or Daily)
      4. Date/time of next run: Monday 12:00 am
      5. Remote backup destination: click Add Remote Destination and select Amazon S3.
      6. Check Enable schedule to run.
    3. Complete
      1. Schedule name: Complete
      2. Backup profile: Complete (Full)
      3. Backup interval: Monthly (or Weekly)
      4. Date/time of next run: Monday 1:00 am
      5. Remote backup destination: click Add Remote Destination and select Amazon S3.
      6. Check Enable schedule to run.

How about you?

Do you know how we can improve the process, or do you have a question? If so, please leave a comment.

Filed Under: 

Want tips to rocket-boost your website?

Simply sign up.

19 comments on “Amazon S3 & BackupBuddy: guide to WordPress backups”

  1. This post remains a draft on my blog. Good work getting it written, recorded, and published! This is my go-to method for backing up, and also works great for site migrations from development to production, or from one URL to another.

  2. This is incredible. I just lost all my backups because one of my clients accidentally deleted the backups. Duh!

    I still have questions about the permissions in the Groups. Why do you select policy Full access? Is it not worth it to select Policy Generator and create a policy where BB or the client can only Put and not delete or is this getting too granular, in your opinion?

    Lastly, What are your thoughts about versioning as a solution for preventing accidental deletions. Specifically, the part about this cannot be turned off, and what costs will it incur?


    1. Jason, it would certainly be better to create a more granular policy, as that fits the principle of least privilege. In theory, you could deny delete permissions to prevent users from deleting backups from S3 using BackupBuddy's interface. Based on what you said during our call, it sounds like that didn't work in practice. I used Full Access because I wasn't familiar with the policy generator, and it wasn't immediately intuitive. If you find policy settings that work better, please leave another comment.

      There are services that provide versioned, continuous backup. I've heard good things about VaultPress and CodeGuard, but haven't yet used them myself.

  3. Hi Chad, I don't know if you've experienced this problem before but when I press test settings I just get the circular loading icon and nothing ever happens. It always used to but now for some reason it doesn't. Other destinations such as Dropbox and Stash still work fine but I would really like to use Amazon S3, Any help would be greatly appreciated as I'm pulling my hair out here 🙁

    1. Paul, I haven't experienced that. I have had the Test Settings button result in a failure message if I click it immediately after adding the user to the group in Amazon IAM, because it's not ready yet. Usually I wait a few seconds, try again, and it works. It's odd that you're not seeing an error message. Check the error log in BackupBuddy (WordPress menu > BackupBuddy > Getting Started > Overview tab > Logging & Debugging window). Also, make sure your Amazon IAM usernames and S3 bucket names meet Amazon's naming requirements.

  4. I was having the same problem with Test settings never finishing, and after much experimentation I found that it was caused by a recent change on my server from php v5.2 to v5.4.

  5. Thanks for the guide! I knew that saving my primary keys to each WordPress site was a bad idea, but wasn't sure how to setup the users.

    The versioning that Jason was (probably) referring to is the versioning system available within Amazon s3. It has archive and delete rules that you can set at the bucket level. Just right click on your bucket and open the properties. Expand the Versioning tab. Turn versioning on then expand the Lifecycle tab to set the rules for archiving and deleting. I set mine to archive after 10 days and delete after 90 days.

  6. This S3 User-group setup leaves you wide open to a catastrophic loss of data across all site backups; all these AWS users you create belong to a group with super-user privileges for S3 storage. Any of these users could do whatever they liked, including accessing backus in, and even deleting buckets unrelated to a given sites backup. Versioning won't save you, if a bucket has been removed.

    Combined with BackupBuddy's need to store the key and secret without encryption in your local db, and you have a recipe for tears if one of your sites gets hacked.

    When creating your S3 user, set an inline policy for them that explicitly gives them privileges for a single bucket

    Not hard, and much safer.

  7. We have an issue with backups timing out in the remote send process. What is best practice for what size file chunks to break up the backup file to and other advanced options?

    1. We've never had that trouble, but here are a few suggestions. In your Amazon S3 destination settings, try changing the Max chunk size to something below the default 80 MB (as low as 5 MB). The problem could be caused by a server timeout; see Why BackupBuddy fails to send backups to a remote server. You could try increasing your PHP maximum_execution_time. You could also try asking your host, checking the BackupBuddy Frequent Support Issues, or contacting BackupBuddy support.

      If you find the solution, please leave another comment.

Ready to Blast Off?

Let's talk.

Contact OptimWise