Hacker News Reader

Comment by sandGorgon | Hacker News Reader

Hmm..there's no restore? So this is like a one way export.

Also Glacier export would be nice for long term cold storage of database backups.

But a restore capability is essential.

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).

Hmm, I wonder why they didn't push people towards DMS instead? This S3 export offering certainly commands a premium price for the privilege.

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.

It looks like this is more positioned to perform analysis on snapshot using other tools and not a backup solution .

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

"I’m interested in an easy backup-out-of-aws solution."

rsync.net has 'rclone' built into the environment[1] so it is trivially easy to call rclone, over SSH:

  ssh user@rsync.net rclone s3:/some/bucket /rsync/account

... 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

Great, thanks -- will take a look at this.

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):

  ssh user@rsync.net rclone .zfs/snapshot/1dayago/bucket s3:/some/bucket

AFAIK rsync.net doesnt work with RDS (which is a managed solution with no ssh access).

I can't speak to RDS specifically, but if you can get RDS into either S3 or Glacier, then there is an easy path to rsync.net: rclone.

The ssh access is not to Amazon, or S3 or RDS, etc. - you run the rclone command at rsync.net, over ssh:

  ssh user@rsync.net rclone s3:/some/bucket local/rsync.net/dir

> 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?

Good point ... we don't have this db encrypted as the DBMS level. Internally sensitive information is encrypted using keys not managed by KMS

The export does type conversion so this is one-way by definition :(.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_...

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.

It is not designed to be a backup mechanism.

Reply on news.ycombinator.com