AWS RDS Aurora – Automated Backups Tab Explained

Amazon Web Services recently announced PowerShell command line tools for Windows and it's packaged along with their AWS Tools for .NET SDK.

The AWS Powershell tools make it quite easy to create a snapshot:

New-EC2Snapshot "vol-371acd04" -Description "My Snapshot"

And you can query your snapshots like this:

PS C:\Program Files (x86)\AWS Tools\PowerShell> Get-EC2Snapshot | more


SnapshotId  : snap-18be2b28
VolumeId    : vol-371acd04
Status      : completed
StartTime   : 2012-12-28T08:17:00.000Z
Progress    : 100%
OwnerId     : 383816850479
VolumeSize  : 30
Description : My Snapshot
OwnerAlias  :
Tag         : {}

Make sure you have the AWS Powershell tools installed and just create a scheduled task that uses a powershell script similar to the snippet above to schedule your snapshots and you should be good.

Updated to query for attached EBS volumes:

To query for EBS volumes attached to your instance and then snapshot each of them you could do something like this:

# Find my instance ID from the EC2 metadata
$myInstanceID = (New-Object System.Net.WebClient).DownloadString("http://169.254.169.254/latest/meta-data/instance-id")

# Query for volumes that are attached to my Instance Id
$volumes = (Get-EC2Volume).Attachment | where {$_.InstanceId -eq $myInstanceID } | Select VolumeId

# Iterate through these volumes and snapshot each of them
foreach ($volume in $volumes)
{
    New-EC2Snapshot $volume.VolumeId -Description "My Snapshot"
}

First, if you take a snapshot, it will include the oplog - the oplog is just a capped collection living in the local database. Snapshots will get back to a point in time, and assuming you have journaling enabled (it is on by default), you do not need to do anything special for the snapshot to function as a backup.

The only absolute requirement is that the EBS snapshot has to be recent enough to fall within your oplog window - that is the last (most recent) operation recorded in the snapshot backup oplog must also still be in the oplog of the current primary so that they can find a common point. If that is the case it will work something like this:

1. You restore a secondary from an EBS snapshot backup
2. The mongod starts, looks for (and applies) any relevant journal files
3. Next, the secondary connects to the primary and finds a common point in the two oplogs
4. Any subsequent operations from the primary are applied on the RECOVERING secondary
5. Once the secondary catches up sufficiently, it moves to the SECONDARY state and the backup is complete

If the snapshot is not recent enough, then it can be discarded - without a common point in the oplog, the secondary will have to resync from scratch anyway.

To answer your specific questions:

Do I need to record oplogs and use those in conjunction to restore after a failure?

As explained above, if you snapshot, you already are backing up the oplog

Should I spin up another instance within the replica set specifically for backups and snapshot that vs. taking snapshots of primary and secondary? If so, we're back to the oplog issue aren't we?

There's no oplog issue beyond the common point/window one I mentioned above. Some people do choose to have a Secondary (usually hidden) for this purpose to avoid adding load to a normal node. Note: even a hidden member gets a vote, so if you added one for backup purposes you can remove the arbiter from your config, you would still have 3 voting members.

Should I snapshot each replica volume and rely on on the replica set completely to cover the time between failure and the last snapshot?

Every member of a replica set is intended to be identical - the data is the same, any secondary can become primary etc. - these are not slaves, every replica set member contains the full oplog and all the data.

So, taking multiple snapshots (assuming you trust the process) is going to be redundant (of course you may want that redundancy). And yes, the whole intention of the replica set functionality is to ensure that you don't need to take extraordinary measures to use a secondary in this way (with the caveats above in mind, of course).