Support

The reason Akeeba Backup exists is that you can't trust your host to keep a backup of your files. I am not being cheeky or dismissive here. I am being pragmatic.

Backups take space. Space costs money. The more (in number) and the more complete backups your host keeps, the more expensive your account is for them. Therefore, it is in your host's business interest to keep the minimum amount of just barely viable backups. Otherwise, they'd have to charge you more, and you'd be going to a different host.

Further to that, your host managing your backups is putting all your eggs in one basket. If their storage suffers a major hardware or software issue, they go bankrupt, their server is damaged, you have a payment dispute etc. you will lose not just your site but also your backup.

This is exactly where Akeeba Backup comes into play. It lets you determine what you back up, how often to back it up, and where to back it up.

It's this last bit that you need to improve in your backup plan. Akeeba Backup allows you (and encourages you) to store your backups off-site. I recommend buying remote storage from a provider other than your current host. Scaleway offers very cheap S3-compatible storage hosted in France (in a former nuclear bunker in Paris) which you can most definitely use with Akeeba Backup's "Upload to Amazon S3" post-processing option; that's what I use for our business site.

Having the backup archives stored off-site, what your host does and doesn't back up is completely irrelevant. You don't care. No matter what, your site backups are under your control, on storage you have specifically bought for this purpose, storage that your host cannot control. You get the final say.

Of course. Here's my tried and true configuration for uploading my backups to Scaleway. 

• Process each part immediately: No
• Fail backup on upload failure: No
• Delete archive after processing: Yes
• Access Key: my SCW......... access key
• Secret Key: as given to me by Scaleway
• Use SSL: Yes
• Enable IPv6 (dual-stack) support: No
• Bucket: the name of my storage bucket
• Signature method: v4
• Amazon S3 Region: "Custom / None"
• Custom Amazon S3 Region: fr-par
• Bucket access: "Virtual Hosting (recommended)"
• Directory: /   I am using one bucket per site, therefore I save everything in the root of the bucket
• File permissions (ACLs): Bucket Owner Has Full Control
• Disable multipart uploads: Now
• Storage class: Standard Storage
• Custom endpoint: s3.fr-par.scw.cloud
• Alternate date format: Yes
• Use the HTTP header Date instead of X-Amz-Date: No
• Include the bucket name in pre-signed v4 URLs: No

Note that I have set up the bucket to be in the Paris region. If you use a different region (e.g. Amsterdam) both the Custom Amazon S3 Region and the Custom Endpoint change. How can you tell what to use? Scaleway gives you the endpoint domain name, e.g. s3.foo-bar.scw.cloud. This is the Custom Endpoint. The part that's between s3. and .scw.cloud (in our example: foo-bar) is  the Custom Amazon S3 Region.

You can, using the "Enable maximum backup age quotas" under "Remote File Quotas". You want to set "Maximum backup age, in days" to 35 (five weeks time seven days in each week) and "Don't delete backups taken on this day of the month" to 1 (to keep the backup taken on the first of each month).