I’ll have to check. I believe I did a file restore as a test. Stay tuned…

Thanks for the update.

To get that type of GFS (grandfather-father-son) retention, you'd have to move to the new backup format. However, the new backup format does not yet support hybrid backups, so you'd have to run two backups - local and cloud. The new backup format has some advantages over the legacy format: Client-side deduplication, synthetic full backups for image, file. VM, backup consistency checks, restore verification for image backups, Immutable backup option and GFS retention.

If you switched to the new backup format, you could set the following on the Retention section

• Set your schedule to run a full every 30 days and incrementals in-between
• Keep your backups for 90 Days (this is the last 3 fulls + associated incremental backups) - Now in order to keep 90, you'll need to keep 120 days before the earliest 30 days can be removed
• Enable GFS option
• Keep Monthly backups for 3 Years - there is no option to keep an end of year backup. You'd probably have to take a manual IBB on the last day of each year using a separate plan without a schedule and without any retention set
• You can Set Yearly to 7 years if you want though as that will retain annual full backups after the 3 years of Monthly backups

The Full backups will be synthetic on Amazon S3 (but not locally on the NAS). You also have the option to create an S3 Immutable bucket and send the backups to that new bucket. Then you can enable the Enable Immutability option (only available if the bucket is created with Allow Immutability - so you'll need a new bucket created).

Immutability uses Governance Mode and the Amazon S3 Object Lock feature to lock your monthly and annual backups according to your GFS settings for the plan.

I realize this is a lot to digest. If you have questions, please let me know.

Jackie, glad you found a temporary work-around. Any chance I can get you to send the logs to Support from the Tools - Diagnostic toolbar option on the client where you were seeing this issue? (You can also do this from the management console on Remote Management from the gear icon on the endpoint in question). I would like for them to review if you have a few minutes to submit. Thanks.

Any luck with the Web UI or with any adjustments to font scaling in the GUI you are using?

I personally don't run into too many customers using one zone IA. I think it's because it's not replicated within the data center like other storage classes. And we do have a lot of customers that just use S3 standard. It's easy for most of our customers to manage and mark up the storage so it's profitable without overcharging customers, even when they're paying for that storage class.

Thanks Steve! There’s some indication in the Google post that storage transfers may be free until end of year. I don’t know if that includes moving objects between storage tiers, but it’s worth investigating. https://cloud.google.com/blog/products/infrastructure/updates-to-google-clouds-infrastructure-pricing

You're looking at the Create Date, presumably. I tend to look at the Modified Date in File Explorer as the default datetime field, but that's just me. We do restore the modified dates.

We likely have access to the file / folder information in image backups. I do not know what we store for File Backups, but you're right that we could certainly restore that information, if saved. We have not had a request to restore create dates until now - it's officially logged as a customer request in the system.

But is having the Modified Date retained from the original sufficient, do you think, for most of your customers?

All right. Rather than going through support, we can try to do this on the forums here. But before we do that I need a very detailed reply from you, which you can DM me or post in the forum, your choice. I need to understand exactly how you have things configured now in a single post so I can write a reply that will help you address the particular concern you're having.

I need to know whether you have storage assigned at the user level or the company level, or both, what types of storage accounts they are, and whether or not there are any storage limits assigned, and if so, where they are assigned. At the company, at the user level on the storage, etc.

The other option is for you to open a support case and have them walk you through the proper process for your environment to get the results you need. I'll let you decide how you want to proceed. Look forward to your reply.

You don't need two users. You can use the same user. Under the user's section you can assign storage and when you do that you can assign storage limits to each storage assigned. You can do that rather than assigning storage at the company level. So you can use two different storage limits, or really just one storage limit for the cloud, and no storage limit for the NAS. Or as another option you can assign the NAS at the company level, and assign the cloud at the user level. But you can use the same user for both. The user is just the account that the agents use to authenticate with the server and allows the management consoles to know what customer they belong to.

There are no strict storage limits that are automatically imposed by the product. If you're hitting a limit, then I am guessing that an admin must have set up a storage limit when adding a storage account to a User. If you check the Organization - Users, click on the authentication user in question, and verify the storage accounts assigned and if there are any storage limits. If there are, you can either edit the Storage Limit from Storage - Storage Limits, or remove it from that User Storage assignment.

Is that what you were referring to?

Please check out this post: https://forum.msp360.com/discussion/2618/page/p1

You're probably not doing anything wrong. Versioning is not officially supported with S3 compatible clouds. I believe there's already an open requirement to address this in a future release but the feature has not been assigned a release yet. I believe someone else on the forum was able to work around the issue, at least temporarily. I'll see if I can dig up that post and place it here for you to review.

I think it's best if you open a support case for this particular issue. You may be able to get around the issue by changing from redtore-only mode to a regular SQL Server trial for the restore, but for best tracking I think it's better to open a support case as they may be able to provide better guidance on how to avoid this issue.

It looks like that's the current behavior of the product. We create the folders at restore time, and those folders will have a create date when the restore is taking place. If you'd like support to note your request you can go ahead and open to support case. I've also sent over some of the case notes and information to the product management team in charge of that product and they may review and add a new requirement in the future.

I guess I would just ask from you to explain in some detail why the folder create date being restored is important. Is there some process that you're doing that relies on it, or is it something that you just noticed and were wondering why the create date was the restore date?

Seems like a font dpi or font scaling issue. I do not know how to adjust that setting on RHEL, Regardless, any way you can switch to using the WebUI instead of the fat client? https://www.msp360.com/resources/blog/taking-advantage-of-web-access-for-macos-linux/

I am checking with the team on how best to address this issue when it comes up. Stay tuned...

Could be you have your font size turned up in Windows. Try setting the font size to normal 100% and see if that temporarily fixes the issue.

Nothing to me, but you can submit logs to support from Tools - Diagnostic and explain what you found. I’ll send this post over to engineering but you should notify support as they’ll keep you posted on what’s going on.

If that's the issue, it might be a bug. So reply backup once you complete that second test and I will send your helpful analysis and results to the engineering team for review.