To cover 5 devices, you should acquire 5 licenses.

It seems like there might be an issue or a bug. Have you already submitted a support ticket for this matter?

So if I want granular backups to go back 6 months (in the event I need to recover files that a user has lost or deleted), — noderaven

In this scenario, the base retention, represented as "Keep backup for," should be configured to a duration of 6 months

Currently it's set to incremental backups daily, every hour. Is this excessive? — noderaven

It all comes down to the specific requirements. Typically, a daily incremental backup suffices, but if a more granular approach is necessary, that can also be accommodated.

I want to keep data for 5 years since in this case, it's for an insurance broker company. But have granular restoration abilities to go back 6-12 months — noderaven

You can implement a combination of monthly and yearly GFS retention in this scenario:

• Monthly retention: 12 months
• Yearly retention: 5 years

When combined with the base retention, this setup will provide 6 months of daily/hourly restore points. From month 7 to month 12, only the monthly full copies will be retained. Starting from month 13, only the yearly full copies will be retained for the next 4 years.

Have you tried to synchronise the repository?

It looks like you haven't updated the software for a while. Can you try with the latest version?

This is really difficult to reproduce. As you mentioned it works on your other servers. It works for me too. I checked with our dev and support teams and they couldn't recall similar cases. It doesn't seem like the software problem. Maybe there is something with the Windows events log service.

The easy way would be to reinitiate the repository db, but that might take quite some time. To do this:
1. stop the service
2. close the agent
3. rename file C:\ProgramData\CloudBerryLab\CloudBerry Backup\data\cbbackup.db (maybe add OLD to the file name)

again, that might take time to recreate the repository from scratch

VSS Error (code: 2404)
VSS System Writer does not have permission to read the service account. Event ID: 513
Read the instructions in the Knowledge Base article — LouVO

Check this KB article https://kb.msp360.com/standalone-backup/general/errors-and-warnings/vss-system-writer-does-not-have-permissions-to-read-service-account

ERROR
An error occurred (code: 1003)
The creation of a shadow copy is already in progress.
Please contact support — LouVO

The issue might be caused by other software for native Windows backup. Make sure another backup is not working at the same time. If this doesn't help, try opening an elevated command prompt, then run the following commands:

• chdir “C:\Program Files\CloudBerryLab\Online Backup”
• .\cbb.exe fixVSS -output full

Also, make sure the backup plan setting "Use system VSS provider" is enabled.
Reboot might help as well

another KB worth looking at if the above doesn't help https://kb.msp360.com/standalone-backup/general/errors-and-warnings/unexpected-volume-shadow-copy-service-error-has-occurred

To grasp the intricacies of the retention policy, it's important to consider a few key points:

1. MSP360 employs a generation-based approach to storing backups, with each generation comprising a full and incremental backup set. The term "generation" is closely tied to your full backup frequency.

2. There are two distinct types of retention: Base retention and GFS retention. Base retention applies to backup generations, excluding the current one, which remains immune to data purging until the next generation is created.

3. GFS retention, on the other hand, is specifically applicable to full backups. It serves as a complementary retention policy that shines when you need to retain full backups for extended periods. Notably, GFS retention should surpass base retention in duration.

In your current configuration, both base retention and maximum GFS retention are set at the same value, e.g. 5 years base retention and 60 months GFS retention, resulting in backups being stored for 5 years anyway.

It's advisable to differentiate between the two:

• Set the base retention ("Keep backup for") to a duration that aligns with your need for granular restore points, typically represented by each incremental backup.
• Use GFS retention for full backups that require storage beyond the base retention period.

Let's illustrate this concept with an example. Although I don't have access to your specific backup schedule, let's assume you perform incremental backups on weekdays and full backups every Saturday. In this scenario, we'll set the base retention period to 1 month.

Base Retention:

Under this configuration, you'll have a maximum of 4 full backup generations (comprising both full and incremental backups) stored at any given time. When the 5th generation is created, the 1st generation will be purged in accordance with the base retention policy.

GFS Retention on Top of Base Retention:

Now, let's delve into how GFS retention complements base retention based on the settings in your screenshot, where weekly backups are stored for 6 weeks and monthly for 60 months.

The first full backup generated will be marked as the initial monthly and weekly backup for GFS. The 2nd, 3rd, and 4th full backups will only receive weekly tags.

When the 5th full backup initiates a new generation, incremental backups from the 1st generation will be purged in accordance with the base retention policy. However, the full backup will be retained based on the GFS retention. Additionally, the 5th full backup will again receive monthly and weekly GFS tags. The 6th and 7th full backups will be tagged as weekly backups, and so on.

Once the 7th full backup is created, the 1st full backup will lose its weekly GFS tag but won't be purged because it still has a monthly GFS tag. It will be retained in accordance with the monthly GFS retention.

Subsequently, when the 8th full backup is created, the 2nd full backup will be purged in line with the 6-month retention period for weekly backups, and this cycle continues.

I hope this explanation clarifies how retention policies work in MSP360 backups. If you have any further questions, please feel free to ask.

1TB limit applies to MSP360 storage trial only. If you are connected to a 3rd party storage, there is no limit.

Speaking of licenses, we charge for the actual license usage at the start of the next month, e.g. you pay for licenses used during the previous month. Once your trial license comes to an end it will be automatically converted to a paid license and at the beginning of next month your account will be charged for the days outside the trial period. No action needed on your end

Your trial licenses will convert to paid in 15 days after the activation. Speaking about storage, you can switch to a paid mode by clicking subscribe at https://mspbackups.com/AP/EditAccount.aspx

I would recommend doing full regularly, yes. The most common frequency among our customers is once per week or once per month. Also what important to understand here is that depending on your retention settings multiple full backups may take quite some space on your storage, so plan your schedule and retention accordingly. Choose a reasonable retention period not to keep more data than you actually need. If you need longer retention for your full backups (months or years) consider using GFS settings for monthly backups.

So looks like this path can not be accessed \\HCU-DC01\HCUdata\Appraisals & Real Estate. Can you send the whole log file in a PM? There is a block with an error description at the end that can help to diagnose.

Can you DM logs to me?

There is an option to force a missed backup on a computer startup.

Can you send logs?

Yes you should be able to start a trial on a new server

You can request license transfer via the contact form at https://www.msp360.com/contact/?category=license . Make sure to pick the right product.

or you can send an email to licenseatmsp360dotcom

It's actually on the website https://www.msp360.com/backup/