I’m interested in an easy backup-out-of-aws solution.
We use snapshots for regular backups, and have implemented a solutions to share and copy snapshots to a different aws account.
But given that our production database is absolutely vital to the existence of the company I’d like to have an easy way to create a secure ‘not affliated with Amazon’ copy regularly in case of the nightmare scenario where an account is compromised/terminated
... and perform arbitrary data movements into, out of, and between S3/glacier/nearline/gdrive resources. Your "out-of-aws solution" contains ZFS snapshots, on any schedule you like, so you can just do a "dumb" sync to rsync.net and handle the retention with the snapshot schedule.
Also, the snapshots are immutable (read-only) so your data gains some protection against ransomware and other threats like accidental deletion.
You should trust us with your backups because we've been doing this since 2001.
The challenge with RDS in the past has always been getting the data easily and scriptable into an S3/etc bucket to start with. This might be a good enough solution.
Restore would be a pain, but at the point its needed the pain would be acceptable.
"Restore would be a pain, but at the point its needed the pain would be acceptable."
I can't speak specifically to this, but I will point out that you can just as easily run those 'rclone' commands in reverse, to move data from an rsync.net snapshot out to (insert cloud):
> We use snapshots for regular backups, and have implemented a solutions to share and copy snapshots to a different aws account.
How do you do this if the db is encrypted? Or rather, how do you restore from the encrypted backup in the second account if the master key in the original account is somehow deleted without anyone noticing and intervening before the deletion becomes finalized?
The snapshots already deliver your desired functionality. This dumps it as a different format. In fact, it probably depends on restoring the snapshot to a database in order to implement this format change.
I think this is a replacement for rolling your own database exports for analytics applications with Sqoop or Spark.
Exporting to parquet has existed for a bit for AWS RDS (via AWS Data Migration Service), but this should make doing so more straightforward (since it doesn't require managing any DMS compute).
AWS DMS also supports incrementals (using the change-data-capture features in the DB).
I just wish DMS supported real-time data synchronization for utf8mb4 on MySQL... That really destroyed my workflow with errors when I moved to utf8mb4 (requirement) and then had to stop using DMS altogether. It’s pretty much the only thing I used from that services.
There are a number of unfortunate shortcomings depending on what your DMS source/target are. Another that bit us was (the lack of) support for JSON types in MySQL sources.
Was there no option to add a transformation to your DMS routine to handle that?
there is a ridiculous price difference between vanilla s3 and managed backup storage. Its close to 10x.
backup storage on postgresql is billed at $ $0.095 per GiB-month
same on Aurora is billed at $0.023 per GB-month
If you include Glacier, then it is 100x. I truly believe that AWS charges these costs because they make a crazy amount of premium with that. And that is why these exports are architected to be non-restorable.
Yes, that's correct, one way export (for now). Once exported you can set lifecycle policies in your S3 bucket to automatically transition to cold storage or deletion.
The canonical AWS answer for things that you want in Glacier that only support export to S3 is to put a lifecycle policy on the bucket to move to Glacier after 24 hours.
One day in S3 = 10 days in Glacier and since Glacier is presumably for years, the cost difference is trivial.
I've run into this need. Generally, you have a DB, you just want to bring it back to a point in time. As RDS instances can be part of a bigger setup, it's not always trivial to point your application at a different instance, so re-using an existing instance can be helpful.
Thats a great feature, if you're on Aurora. In my case these were MySQL RDS instances created ranging from 2012 and beyond. Migration of the app to Aurora is possible (after testing), but it would be a much larger change.
Would you sign your first born over to me on that promise? Obviously I'm joking, but i have in the past got nervous that there might be issues with this claim. I.e. previously i found that the MySQL welcome banner that Aurora gave me claimed it was a very specific version, but when i tested a bug fixed in a previous MySQL version (a weird edge cases for us around transactions) it failed the test. I'm worried that while the goal is for it to be 100% compatible, the number is closer to 99.X% and that means the migration isn't a small amount of work to verify.
That is what I did back then, i actually got a great response and the explanation of why this issue existed was valid. Not a real concern, I just don't love the way Amazon suggests "use Aurora" all the time when the real issue from the customers perspective is "Other non-Aurora RDS offerings are lacking features, and we have to keep using them - at least for now".
Aurora compatibility with MySQL is great. But as any 100% compatibility claims this one is bullshit. You can get close but you never really quite hit 100%
I am imagining a scenario where the instance is shut down and restored to a point-in-time snapshot. The UI suggests this is possible based on the verbage, and this is an expectation of lots of other DB management tools.
At the moment, when you try and click 'Restore to point in time' it's just taking you through the new instance wizard with the snapshot being used as the initial dataset. Screenshot: https://i.imgur.com/vBiqgJg.png -- the 'restore to point in time' is extremely misleading.
My specific uses case would be for PostgreSQL and/or MySQL, I do not use nor have I tried Aurora.
I need to grab a single row out of a snapshot from our staging database. So far I have restored the DB once and our QA team was able to reproduce a bug. They began testing prior to me pulling the data out, so now I am re-cloning an instance to fetch the unmolested data from that DB.
tl;dr - allow me restore a snapshot like every other piece of software that has a snapshotting component. caveat is that this will likely need to be an offline process, but as long as that is noted and clear, that is going to help a LOT of people out.
> allow me restore a snapshot like every other piece of software that has a snapshotting component. caveat is that this will likely need to be an offline process, but as long as that is noted and clear, that is going to help a LOT of people out.
We have this in Aurora already. If you migrate to Aurora (which is MySQL/Postgres compatible), you'll get this functionality out of the box.
Is there a 'clone this database, but as an aurora database, and make it a replica that can eventually become standalone' feature?
Most of my RDS usage is for my clients, so it is not always feasable to up and forklift them to a different database platform.
I would imagine though that AWS is not going to invest a lot of time and energy into improving the developer ergonomics and UX of non-Aurora databases?
I can't think of anyone who would choose Aurora right off the bat -- becuase it's one click closer to complete vendor lock-in and away from OSS.
We have a few mysql instances where we only need them for a few days a month (maybe a week).
Because a stopped instance will start automatically after 7 days we delete the instance and do a final snapshot.
When we restore we have to go through the process of configuring a new instance from that snapshot.
Where you have to select the security group, availability zone, set it to not public (which btw revert to yes once you select some availability zone) etc.
This process is rather error prone and honestly annoying if you do it multiple times.
Are there lightweight solutions to reading parquet files in Python? Any time I want to deal with parquet in AWS lambda I have to deal with the entire Pandas suite which is a pain on lambda.
What happens to bandwidth saturation on the backup database/RDS host? is it unlimited? Capped? user-defined? i.e. would backup impacts the ongoing transactions/packet transfer?
Excuse me for technical illiteracy, but would that make sense to export these snapshots daily? Is there any way to consistently get the (every 24h) data from the database in S3?
Let’s say I have a database with 1TB of data. I export it daily to S3 with this Snapshot export. Does it mean I will be adding 1TB every day to my S3 storage?
I use rds Aurora but i run a daily cron job to export the entire thing with mysqldump + gzip to s3.
I pass some flags to mysqldump to avoid locking the db and otherwise interfering with production. It also dumps from the reader node not the writer.
I also clear some tables and restore it daily to a development DB.
Sadly this looks like it only supports parquet, a rather usual db dump format. Even if, I'm sure, it's way more efficient to process using some modern tools than a text sql dump.
I just like open formats and interoperability and AWS's rds offerings are always just slightly 'off'.
Parquet is an open format. It’s part of the Apache foundation.
Would have preferred CSV as well, though, easier to work with. There’s also a little known feature called S3 Select that allows you to run SQL on S3 files and selectively retrieve data, which is what Parquet is for in the first place.
I don't think this is meant for recreating the database, but rather exporting large sets for analysis somewhere else. But as far as tools yes, parquet can be parsed by any tool that knows the format. It's not too uncommon
Great news. But unfortunately, it is not the original data snapshot as the title says, it's Apache Parquet format. So this is useful for analytical tasks only.
For operational tasks, still, the only option (besides RDS cloning) for Postgres is pg_dump or pg_transport, losing physical layout.
64 comments
[ 3.3 ms ] story [ 132 ms ] threadAlso Glacier export would be nice for long term cold storage of database backups.
But a restore capability is essential.
We use snapshots for regular backups, and have implemented a solutions to share and copy snapshots to a different aws account.
But given that our production database is absolutely vital to the existence of the company I’d like to have an easy way to create a secure ‘not affliated with Amazon’ copy regularly in case of the nightmare scenario where an account is compromised/terminated
rsync.net has 'rclone' built into the environment[1] so it is trivially easy to call rclone, over SSH:
... and perform arbitrary data movements into, out of, and between S3/glacier/nearline/gdrive resources. Your "out-of-aws solution" contains ZFS snapshots, on any schedule you like, so you can just do a "dumb" sync to rsync.net and handle the retention with the snapshot schedule.Also, the snapshots are immutable (read-only) so your data gains some protection against ransomware and other threats like accidental deletion.
You should trust us with your backups because we've been doing this since 2001.
[1] https://rsync.net/products/rclone.html
The challenge with RDS in the past has always been getting the data easily and scriptable into an S3/etc bucket to start with. This might be a good enough solution.
Restore would be a pain, but at the point its needed the pain would be acceptable.
I can't speak specifically to this, but I will point out that you can just as easily run those 'rclone' commands in reverse, to move data from an rsync.net snapshot out to (insert cloud):
The ssh access is not to Amazon, or S3 or RDS, etc. - you run the rclone command at rsync.net, over ssh:
How do you do this if the db is encrypted? Or rather, how do you restore from the encrypted backup in the second account if the master key in the original account is somehow deleted without anyone noticing and intervening before the deletion becomes finalized?
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_...
I think this is a replacement for rolling your own database exports for analytics applications with Sqoop or Spark.
AWS DMS also supports incrementals (using the change-data-capture features in the DB).
Was there no option to add a transformation to your DMS routine to handle that?
backup storage on postgresql is billed at $ $0.095 per GiB-month same on Aurora is billed at $0.023 per GB-month
If you include Glacier, then it is 100x. I truly believe that AWS charges these costs because they make a crazy amount of premium with that. And that is why these exports are architected to be non-restorable.
One day in S3 = 10 days in Glacier and since Glacier is presumably for years, the cost difference is trivial.
Can you tell us more about the use case? I'm not sure I understand the need here, or how it might improve your work patterns.
Also, note that this is an export feature, not a backup/restore feature. Aurora already has native backup/restore: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
https://aws.amazon.com/about-aws/whats-new/2018/05/amazon-au...
(EDIT: I should have said "wire and protocol compatible" as opposed to "100%". I regret the error.)
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
The following features are supported in MySQL 5.7.12 but are currently not supported in Aurora MySQL 5.7:
Group replication plugin
Increased page size
InnoDB buffer pool loading at startup
InnoDB full-text parser plugin
Multisource replication
Online buffer pool resizing
Password validation plugin
Query rewrite plugins
Replication filtering
The CREATE TABLESPACE SQL statement
X Protocol
And we want to maintain large number of multi-terabyte backups (that are RESTORABLE) in Glacier for compliance reasons.
There is orders of magnitude of cost difference between snappshots and Glacier. Also i cant maintain beyond 30 days.
At the moment, when you try and click 'Restore to point in time' it's just taking you through the new instance wizard with the snapshot being used as the initial dataset. Screenshot: https://i.imgur.com/vBiqgJg.png -- the 'restore to point in time' is extremely misleading.
My specific uses case would be for PostgreSQL and/or MySQL, I do not use nor have I tried Aurora.
I can't get the S3 export to work either. Screenshot: https://i.imgur.com/nabbsMr.png
I need to grab a single row out of a snapshot from our staging database. So far I have restored the DB once and our QA team was able to reproduce a bug. They began testing prior to me pulling the data out, so now I am re-cloning an instance to fetch the unmolested data from that DB.
tl;dr - allow me restore a snapshot like every other piece of software that has a snapshotting component. caveat is that this will likely need to be an offline process, but as long as that is noted and clear, that is going to help a LOT of people out.
We have this in Aurora already. If you migrate to Aurora (which is MySQL/Postgres compatible), you'll get this functionality out of the box.
Most of my RDS usage is for my clients, so it is not always feasable to up and forklift them to a different database platform.
I would imagine though that AWS is not going to invest a lot of time and energy into improving the developer ergonomics and UX of non-Aurora databases?
I can't think of anyone who would choose Aurora right off the bat -- becuase it's one click closer to complete vendor lock-in and away from OSS.
Again, both are compatible with the open-source versions, so you can export your data if you need to via the standard tooling.
When we restore we have to go through the process of configuring a new instance from that snapshot. Where you have to select the security group, availability zone, set it to not public (which btw revert to yes once you select some availability zone) etc.
This process is rather error prone and honestly annoying if you do it multiple times.
https://aws.amazon.com/blogs/database/aws-dms-now-supports-n...
I pass some flags to mysqldump to avoid locking the db and otherwise interfering with production. It also dumps from the reader node not the writer.
I also clear some tables and restore it daily to a development DB.
Sadly this looks like it only supports parquet, a rather usual db dump format. Even if, I'm sure, it's way more efficient to process using some modern tools than a text sql dump.
I just like open formats and interoperability and AWS's rds offerings are always just slightly 'off'.
Would have preferred CSV as well, though, easier to work with. There’s also a little known feature called S3 Select that allows you to run SQL on S3 files and selectively retrieve data, which is what Parquet is for in the first place.
For operational tasks, still, the only option (besides RDS cloning) for Postgres is pg_dump or pg_transport, losing physical layout.