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.
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.
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!
Relevant content
- asked a year ago
AWS OFFICIALUpdated 7 months ago- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 7 months ago
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.