Amazon Aurora Adds "Backtrack" Feature to Enable Rewinding a DB Cluster to a Specific Point in Time

| by Steef-Jan Wiggers Follow 7 Followers on May 24, 2018. Estimated reading time: 3 minutes |

Amazon Aurora, a fully-managed relational database service in AWS, is now offering a backtrack feature. With Amazon Aurora with MySQL compatibility, users can backtrack, or "rewind", a database cluster to a specific point in time, without restoring data from a backup. The backtrack process allows a point in time to be specified with one second resolution, and the rewind process typically takes minutes. This new feature facilitates developers in undoing mistakes like deleting data inappropriately or dropping the wrong table.

The new backtracking feature within Amazon Aurora allows a user to "rewind" a database (DB) cluster to within one second of a specified point in time. The backtracking documentation states that this feature is not a replacement for running and maintaining regular backups of DB clusters. However, backtracking provides the following advantages over traditional backup and restore: the DB cluster can be backtracked to a time before a destructive action with minimal interruption of service; backtracking a DB cluster doesn't require a new DB cluster, and instead "rewinds" the DB cluster in minutes; earlier data changes can easily be explored -- users can repeatedly backtrack a DB cluster back and forth in time to help determine when a particular data change occurred.

Amazon announced the backtrack feature for Aurora two weeks ago, which currently only works for MySQL databases. Furthermore, developers have to opt-in for the backtrack feature for all newly-launched Aurora database clusters or clusters that they restore from a backup. After enabling the backtrack feature, AWS provisions a First in First Out (FIFO) buffer in the Aurora database cluster. During the use of the database cluster, Aurora will leverage a distributed, log-structured storage system; each change to any of the databases will generate new log records, which are identifiable by a so-called Log Sequence Number (LSN). Moreover, these LSNs are stored in the buffer, allowing quick access and recovery.

When a developer wants to initiate a backtrack, they can pause their application, open up the Aurora console in a browser, select the cluster the application uses, and click Backtrack DB cluster.


The next step for the developer is to choose the desired point back in time and execute the backtrack by selecting the "Backtrack DB cluster" option. Subsequently, the developer can monitor the execution of backtrack in the console -  a process which consists of the Aurora database service pausing the database, closing all open connections, dropping uncommitted writes, and waiting for the backtrack to finish to resume normal operations. The console will notify the developer when the backtrack is complete. 


Arjen Schwarz, a Lead DevOps engineer/AWS delivery lead at Bulletproof, wrote in his weekly notes blog post about the backtrack feature:

If you have experience with restoring an Aurora database, you’ll likely be aware that restoring a snapshot onto a new cluster can take almost an hour. Rolling back with Backtrack instead is a matter of seconds, and you can roll back to the exact second you wish as well. This means that if you need to roll back because someone ran the wrong query, or because of a failed rollout of a new version of your app, you can do so without losing any data or time.

Note that when a developer backtracks too far, they will be able to backtrack to another point in time -- this feature effectively allows a developer to "scrub", or search, across the timeline repeatedly. Moreover, the Aurora service has cloning, backups, and restore capabilities designed to work with the new backtrack feature. 

Aurora backtrack feature is available in all AWS regions where Amazon Aurora runs. The cost of this new feature is about $0.012 per one million change records for databases hosted in the company’s U.S. regions, with slightly higher prices in Europe and Asia. For details, see the Aurora pricing page.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Inventing Internet by srinivasan balram

Al Gore "invented" internet --- Amazon "invented" Point-in-time-recovery --- Valley recovery from NoSQL Kool-Aid continues...

Re: Inventing Internet by Daniel Bryant

I don't think AWS are claiming to have invented point-in-time recovery Srinisvasan, and they have provided similar functionality with the RDS offering for quite some time. One of the main benefits of the Aurora approach is the speed at which the recovery can be made.

Re: Inventing Internet by srinivasan balram

Oracle has flashback since '05 -- SQL Server, Postgresql support temporal tables. So, it's not clear why Amazon thinks their feature is special. If they are talking about speed of db recovery -- it's not clear if it's relative to standalone db cluster, in VMs or container -- since there are no benchmarks. What config (CPUs/SSDs/memory/network) setup should let us believe their claim?

Re: Inventing Internet by Daniel Bryant

I believe that Amazon thinks this feature is special, because they haven't had it previously :-)

In all fairness, I think we are comparing apples-to-oranges with Aurora and other RDBMS. I've used many of them, and as Aurora is offered as a fully-managed service, the biggest differences are the ease of operation (especially scaling) and total cost of ownership.

I'm definitely a big fan of benchmarks, but the Amazon team aren't making any comparisons with existing tech in their recent posts, only that point-in-time recovery with Aurora is in the order of minutes. If you're interested in this space, the Amazon team have previously released a white paper that describes one approach to benchmarking:

Re: Inventing Internet by srinivasan balram

TLDR --> Not much hardware savings.

That was a good paper. Thank you.
One issue was there was no info on any hardware used to get to those numbers. I took that paper as a starting point and did a rough estimate for i3-metal instance type -- for erp/bi -- type work -- i3 costs $5.50 per hour -- for a year it's $40k -- 8000hrs/yearx$5 (approx)

Based on current hardware prices, building i3 server would cost $36k (approx)
Intel Xeon E5-2686 2.4 GHz v4 – 14 cores-- $2700 x 4(72-cores) = $10,800
Samsung NVMe 960 Pro – 2TB -- $1300 x 8 = $10,400
Crucial 128GB DDR4 -- $4000 X 4(512) = $16,000

It's still apple/orange -- Maybe for i3 metal, building is cheaper?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you