1. The only reliable way to determine that is doing test restorations. There's BackupMonkey.io which can do that. Or you could do a test restoration once a week or once a month (depending on what is considered an acceptable possible loss for you).
You could of course automate that on your own box with UNiTE — that's what BackupMonkey does — but I assume that if you are asking this question you don't know how to set up your own local test server and CRON jobs to run UNiTE.
2. You can do something like that but it's kinda tricky. You need three backup profiles:
- Runs on the 1st of each month and has a count quota of 12. This is the monthly backup you keep for a year.
- Runs each Sunday except the 1st of the month and has a count quota of 4. This is the weekly backup you keep for four weeks.
- Runs every day except Sundays and the 1st of the month and has a count quota of 7. This is the last 7 daily backups.
It makes more sense to back using day-based quotas and count quotas. You can set up the day quotas to keep the last 30 backups, always keep the backup on the 1st of the month and set the count quotas to 42 (30 daily backups + each of the 12 months). This is more backups than what you said but at least it's automated with a single backup profile.
On our main backup profile I do 30 daily backups and keep the one from the 1st of each month, uploading everything to Amazon S3. I have set up lifecycle rules on the S3 bucket for backups over 3 months old to be set to Intelligent Tiering, backups over 6 months to be moved to Glacier, backups over 12 months to be moved to Glacier Deep Archive and backups over 10 years old to be deleted. The idea is that I will very likely need a hot backup from the last 3 months to restore as a dev site, backups 3 to 6 months are less likely to be restored e.g. to see the state of the site because someone deleted their account and they contacted me about a subscription they had, backups between 6 to 12 months are extremely unlikely to be needed for restoration (only happened once in 12 years) and the rest 9 years is what I am obliged by law to keep as a proof that transactions involving money changing hands really did happen in the way described in the company's books (the law says we're obliged to keep at least 7 years and the tax office guidance is ideally 10 years because a legal case could move slowly enough to warrant the additional three years; beyond a decade the statute of limitations has expired).
The S3 transitions are explained in https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html. Do note that they are based on the object (file) age in days, not the date it was created. That is to say, you can't tell it to keep weekly backups or monthly backups. All transitions have to be about the age of the file in days. So what you are trying to do cannot be implemented. You could, however, do the following:
- Set Akeeba Backup to take a daily backup and send it to Amazon S3. Enable remote quotas, enable the day quotas for 30 days and keep the 1st day of each month.
- On the S3 bucket set the following transitions:
- After 30 days: move to S3 Standard-IA. There's a minimum of 30 days Standard storage requirement on S3. So, your last 30 days will be your hot backups. Then your monthly backups for the past 3 months will be nearline but not hot.
- After 90 days: move to S3 Glacier Instant Retrieval. Your backups from 3 months ago to 6 months ago will need a few minutes to be retrieved. They are in your cool storage.
- After 180 days: move to S3 Glacier Deep Archive. Your backups from 6 to 12 months ago will take a few hours to be retrieved. They are your cold storage.
- After 365 days: expire (delete). You only want to keep up to one year of backups.
This is a good policy and rather cheap. With 1GiB backups stored in Amazon's Paris datacenter you'd be paying under $10 a year (pricing: https://aws.amazon.com/s3/pricing/). I think that paying less than the price of a large pizza and cola per year to be able to sleep at night without worrying about data loss is well worth it!
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!