Open GeorgeBellTMH opened 3 years ago
For API it may be useful to have @backup(frequency: xxx, retainDuration:) that can be defined on each table. Or to be able to use point in time for any or all tables.
For auth it would be useful to be able to backup the user information and group membership (even if passwords aren't backed up) with the option of selecting which custom fields (or all of them) get backed up. Optionally this should be able to be backed up in an encrypted format.
For storage it would be useful to have rules around how the backups are made, including wildcards to define what to backup, how long to store, what type of s3 storage to use etc.
All backups would ideally end up in an S3 bucket on either the same or a different region. Also it would be nice if they could be downloaded and stored outside of Amazon if necessary.
Any news?
Up
Up
Also add Disaster Recovery mechanisms
As someone who was just bitten by this, it would really be nice to have backups be part of amplify.
1) DynamoDB turns on Point in Time Recovery 2) S3 replicates to another bucket 3) Cognito replicates to another pool
The backups ARE NOT deleted if and when the amplify app is deleted.
And add a command like
$ amplify restore-from-backup
This feature would be really essential for us. We are building a solution that will soon need to be released in production soon and it's completely built on Amplify. I have to admit that I have only started on AWS/Amplify over the last couple of months, but I don't see how one can build a production-ready application without this feature and some goes for the topic reported in aws-amplify/amplify-category-api#180. While waiting for this to be hopefully implemented, if anyone can share the solution they are using it would be super helpful. I was going to use AWS Backup, configuring a backup plan based on tags (for graphql API/DynamoDB). Just a thought: compared to implementing aws-amplify/amplify-category-api#180 which I can understand would be quite hard, taking care of this feature request looks like an easy win that would provide so much value to the community.
If the amplify team is reading, an RFC on Data Backup/Site Backup/Failover would be great!
It would be great to get some feedback on this from the amplify team, on whether they have any plan to implement this feature in the future or whether it's never going to happen.
Any update?
Up!
Up too
Any update?
Waiting for the feature to be available in AWS Amplify, I paste here my solution implemented using AWS CDK
const plan = backup.BackupPlan.dailyWeeklyMonthly5YearRetention(
this,
'Plan'
)
const branchName = process.env.AWS_BRANCH
const dynamodbTableHash = 'your-hash' // dynamodb table names are like 'name-hash-branch'
let tables = []
let tableNames = [
'table1',
'table2',
// list here your tables names. I did not find a way to dynamically read it as a Amplify output
]
tables = tableNames.map((name) => {
const dynamodbTableId = `${name}table`
const dynamodbTableName = `${name}${dynamodbTableHash}${branchName}`
const dynamodbTable = dynamodb.Table.fromTableName(
this,
dynamodbTableId,
dynamodbTableName
)
return backup.BackupResource.fromDynamoDbTable(dynamodbTable)
})
let resources = [
backup.BackupResource.fromTag('stage', 'prod'), // All resources that are tagged stage=prod in the region/account
].concat(tables) // DynamoDB tables
plan.addSelection('BackupSelection', {
resources,
})
For completeness, I dynamically populate dynamodbTableHash
using a switch-case based on branchName
to target the different Amplify environments.
2 years and no response from the team. Nice!
Well @Straubulous put a p4 on this which I assume means the lowest priority...so I guess the Amazon folks just really trust their infrastructure - despite all the complaints about losing data...
And it appears the cli folks in the other ticket are ok with just editing property files...what's the point of a cli if major functionality has to be done in vi....
Any update?
This is an issue for us too, and it's worth pointing out that while editing the global parameters.json
to set the DynamoDBEnablePointInTimeRecovery
flag to true
(as outlined in aws-amplify/amplify-cli#2186) is a welcome respite, it's not ideal:
Not least because we'd like to be able to set this flag on certain environments only and not all of them - e.g. enable backups in Prod and UAT, but not in lower environments such as individual developer environments.
We really need this. We are testing our app built on Amplify and this is the last piece of a huge puzzle.
I just published a blog in the AWS Storage channel last week that provides the definition for a CDK custom resource to setup backups with AWS Backup. Take a look and see if this solves for your need.
All services that store data should have a way to setup backups
amplify add storage
amplify add api
amplify add auth
amplify backup (creates a point in time backup) amplify restore [backup-date/time]