AWS Backup Dynamo - best practice for my setup

0

Good afternoon all. I have a DynamoDB that stores data in monthly tables and some central ones. Once the month is over, that data doesn’t change. Those monthly tables and other critical tables have PITR on and after the 35 days, I don’t need that on as the data doesn’t change but also don’t want/need to back them up daily. So the question is

From the reading (https://aws.amazon.com/backup/features/) it appears that its a full, then incremental, so after the 35 days and the table stops being written, can I leave the backup flag on (since nothing changes, I shouldn’t pay any additional) right and only the new tables/data will be written?

Bonus: (this may have to goto the dynamo forum), but after the 35 days, if that table doesn’t change does PITR continue to charge, and if so, can something in the AWS backup job say turn it off after x days?

Thanks all

posta 2 anni fa392 visualizzazioni
3 Risposte
1
Risposta accettata

Can you leave the PITR on after 35 days? Yes, if you'd like.

Will it continue to charge? Yes, because you pay by the GB consumed in the backup. Even without writes, the PITR backup consumes space.

Can you turn it off? Yes. If you do then unless you have another backup (On Demand) you'll lose a recovery path should someone accidentally delete any data.

Side note: You might consider changing tables for previous months to the newly introduced Standard-IA table class, if the tables don't see much read traffic. It could provide a cost savings.

Last note: There's another recent feature where DynamoDB integrates with AWS Backup and this would let you do an On Demand backup when "closing" the table and have AWS Backup migrate the backup to cold storage.

AWS
con risposta 2 anni fa
profile picture
ESPERTO
verificato 9 mesi fa
0

So @jzhunter - I setup a backup job and the resource is setup by tag. I have some old static tables and can see I have 12 recovery points, and I see the same table daily for a week.

So from what I understand, if the table didn't change, I am not charged, however, with multiple restore points, I think its taking up the space multiple times so I am charged, does that make sense?

So, the right plan would be PITR on for the tables that change and continue to backup via AWSbackup. After 45 days, remove the PITR and remove the backup flag knowing the latest is the most recent.

As a fail safe, I can add a tag like quarterly snapshot and let that backup as a just in case but again if its not changing, that maybe overkill.

con risposta 2 anni fa
  • Hi, sorry to be slow in response, I wasn't beeped about your reply.

    It depends on your motivation for doing backups. PITR is good for recovering from a user or application error, where perhaps some items get deleted erroneously and you want to undo that delete. On-Demand backups (also backups managed via AWS Backup) are good for long term storage of a snapshot as of a point in time. If your table isn't changing and you've got a snapshot made since the last change, then there's no value in keeping PITR, or even in continuing with more daily backups.

    Perhaps you could enable PITR backups while the table is live and keep a singular On-Demand backup after it's frozen.

0

Ah ok ... so from what you say, I should do the following (and do this programmatically) ....

After the 35 days of PITR, that YYYY-MM table becomes static, and with much less reads, I think the Standard-IA is a great idea. I am just not entirely sure I follow about the PITR cost and/or recovery. How I logically thought about it, was if on 12/1 the 2021-12 table was created, PITR enabled, AWS backup will still pick it up due to the backup tag. On 1/5 (give or take), no new data will goto the 2021-12 table, so I should be able to turn that PITR off. No data will change, so aws backup already has that table, so if anything ever happened I could just do a restore of that table by itself. With that, I would assume i would pay more in December due to PITR as well as AWS Backup, but then in January, that storage change and PITR end would save and I would have that table in AWS Backup.

As the aws backup job runs daily, since that table never changed, I would never need to do an onDemand backup, but as you said, I could set that backup job to transfer to cold after X days knowing it would only be if an emergency hit.

Thank you for the quick reply, as I haven't had much experience with AWS backup, but seeing how powerful it is, trying to move more to it!

con risposta 2 anni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande