Currently we use Rundeck to call your product on the command line to request download from Amazon of the specific full/diff files that we need, so they can be restored in an automated process.

You can run the fulls as frequently or as infrequently as you want. I assume you don't need all backups for the last 10 years, is that correct? Or are you keeping every single full and every single differential for every single database for 10 years? I guess I would need to know that to provide some guidance on retention settings.

Yes, we're keeping every full and every differential of every database for 10 years. We have a similar pattern (with 6-12mo retention) with some other application or image-based server backups where in software we have weekly or monthly full backups and then weekly or daily differential backups, going to local storage.

We do not currently have any use cases with MSP360 where we need to restore an entire system to a specific point-in-time, we merely need certain specific files (which are immutable and don't change) downloaded.

The confusion has been how to set GFS settings so we can do recovery of the specific backup files we need for a given database, application or server without having to restore everything that was ever backed up, or incurring additional Amazon storage costs. I feel like this should be simple but for some reason it's just not clicking for me.

In my case, the SQL backup maintenance plan is as follows:

Full - Weekly
Differential - Daily
T-Log - Hourly

Each goes into a folder like Backups\Full\DBName, Backups\Diff\DBName, Backups\Log\DBName. Each backup goes into a unique file with a timestamp in the name.

Once per week, just before the full backup, a job runs to delete all the previous week's backups off of disk.

By such a time, the assumption is that all backups are stored on Amazon, in the case of Full/Differential the last ten years, and in the case of t-log the last 90 days.

Several times per week we need to restore a full, diff, and log from Amazon to reproduce reported problems.

With respect to the GFS settings, what would I set for retention to get closest to my goal, assumption I do weekly 'full' and hourly 'incremental' on the MSP360 side?

I think my biggest stumbling block is just understanding what is meant by full vs incremental backups in this context; I understand the fulls are synthetic, but if we produce (for example) 1 TB of SQL backups per day, delete them after a week and store each on Amazon to pull individual backups as needed, then when the synthetic full runs once a month, are we going to have a 30 TB object in Amazon as a synthetic full? It would be paying for a lot of storage in an unusable form in that case.

Yes, we're using the SQL native full/diff/t-log scheme as you say, then using MSP360 incremental jobs to backup the files in place of a previous VEEAM/tape arrangement.

Really that's all we want or need, just a way to punt files to Amazon on a schedule and get email alerts when it fails for whatever reason. Don't have a use case for SQL integration per se, these files could be generated by anything (e.g., mariadb).

I get the feeling there's a way to do what I'm looking for (immutability for files on the job which currently backs up the full/diff .BAKs), but I'm not sure how that translates to GFS settings. Intuitively I feel like we have a very simple use case?

That's useful in a lot of cases I suppose, in our case we are using MSP360 with Amazon/Glacier as a tape alternative for a series of existing SQL maintenance plans which produce full, differential and transaction-log backups, and have no need or desire to do bit-level backups of the whole system (also since VSS/shapshoting of those VMs causes too much transaction latency for production workloads) , so we end up using incremental backups in MSP360 to back up those full/diff/log files.

Basically, we have these servers that populate with backup files which are then automatically deleted after several days; between creation and deletion, they need to be backed up for long-term storage, which is where we need immutability. Currently we have one incremental 360 job for full/differential backups and a second for log backups.

Our auditors recently flagged this as an area of concern, since currently these are not immutable.