I think you have it right. If you're not backing up to the NAS, and instead want to back up files on then as from say a Windows computer, then that computer should have access to the network share on the NAS. These easiest way to do that is with Windows security and the network share utilities on your Synology NAS. NET USE is not the best way to do it and you may run into issues where you lose access.

You want to create a network share on the Synology device and ensure the computer running backup has access to that share. If it's more than one computer, then they should all have access. If the access requires credentials, then they need to be entered. The account doing the connecting is the account you are using for the backup service on those machines in question. You do not want to map drives as they are specific to the user creating them and likely will not be accessible to the service account. You should be able to enter credentials from remote deploy. But I wanted you to check the agent where it was deployed to make sure those credentials were properly transmitted with remote deploy.

Can you verify if the credentials were properly migrated to the agent by opening up the agent and looking at the storage accounts and checking the credentials there?

could you try running it with your antivirus disabled? Can you verify the exact version you have as well and the edition of the product. Thanks.

Yes. Under the filter option on the dialog when you create the group report you can select a specific company if you want.

From support.

I can see in the forum that the customer is reporting their issue is happening on Windows 10 as well, so I would think this is more likely an issue caused by something in their network than it is by Windows 11. They could possibly have a domain controller or a host server that is changing their time which would be recorded as a Windows event.

Windows Event log (SYSTEM) usually records such an issue as "An application or system component changed the time" message from Kernel-General (Event ID 1):


It also seems interesting to me that they are reporting this just a few days after daylight savings happened. Knowing how far off the time is getting would be helpful in determining if that has anything to do with it. It's hard to say for sure without the logs which would say how far off the time was.

Have you checked under Reporting? There are reports for License Usage, Billing, and Storage Usage, depending on what you need. Let me know if any of them work for you. If not please describe here what you're looking for. Thanks.

I'm checking with the support team to see if there's anything other customers have reported when running on Windows 11. I don't think we're officially certified on that platform yet, but that should be remedied in the upcoming release. I'll report back when I hear from the support team.

Are you using the free Remote Desktop or Managed Remote Desktop?

Currently, there is no support for connecting to remote Mac systems. You can only connect from a Mac to Windows with the current release. If you are using the free version, then a macOS agent for controlling a remote Mac will be released very soon. If you're using Managed Remote Desktop, we do not expect that agent to release until early next year.

At least that's some improvement. Let's see if things improve again after the server upgrades on the 16th. But keep me updated in case things degrade before then. The more information I have, the better.

What version of Windows Server are you using? Is this on a physical machine or a virtual machine? If virtual, which virtual platform? Also have a look athis KB article:

https://kb.msp360.com/standalone-backup/general/system-time-issues

I checked with the team and they already have a couple planned updates that will take place over the next week to the service to help customers with this issue. I would say if you do not see this issue go away by the time the Managed Backup Service is upgraded on the servers to version 5.3 (planned for November 16), then let us know in this thread. You may see some improvements by tomorrow with the first set of performance updates.

Thanks for letting us know. If you have any future questions please post them here. Thanks.

Please keep in mind what Steve said. If you have a 90 day retention requirement with Wasabi with your account, then deleting backups way before the 90 days' is up, leaves you with fewer backups and no reduction in backup storage costs since you'll be charged an early deletion fee. At that point, unless you have a reason you do not want to keep those older backups around, you might be happier keeping a months' worth of backups so you have more restore points available for restores. Just something to consider.

If you use our Unified Billing Powered by Wasabi, we only require a 30 Day retention. But you're assessment is correct: If you keep data for a single backup and you have a retention requirement on your backup storage, then you're likely going to pay for more than 1 backup. Depending on your region, you could use Backblaze B2.

Are you using the new Image Backup Format or the legacy format? In order to keep different versioning between cloud and local, you'll either need to use the legacy format and select different Retention policies for each:
1 - Cloud: Keep Number of Version to 1
2 - Local: Keep number of versions as needed
3 - Schedule: Recurring Advanced. Run the Full backup as needed. Run Block-Level Incremental in-between full backups.

The limitation here is that you cannot use Synthetic Full Backups as they are not supported for local backups, so every full image backup will have to run in it's entirety.

The better option is to use the New Backup Format which has better performance and built-in integrity and restore verification (if needed). You would create different backup plans for local and cloud (Hybrid Plans are not yet). For the cloud backup, we use synthetic fulls. You can schedule the Full to run something like once a month and incrementals daily. If you set retention to keep backups for 1 day, then the old backups will be removed when the new full is created (meaning, you'd have a full plus a month of incremental backups in storage, then the next full is created and the previous backup set would be removed at that time). If you set retention to keep backups for 1 month, then the previous backup set would not be removed until the send month was complete, meaning, you'd have 2 full months in storage for a while.

Can I ask in what region you are located? If cloud costs are a concern, there are low-cost cloud storage options that might work for you (depending on where you are located).

both options are available to our customers. So you should use the one that you feel is best for your MSP and your customers. As far as deleting, other than deleting the entire set of backups for a particular computer, as an example when you're decommissioning an endpoint from backups and no longer need them; this is supported in the management console from the Users page. For other deletes, you would either have to enable delete functionality temporarily and perform the deletes from the agent or delete them directly in backup storage and synchronize.

deleting backups from the agent has been disabled in the latest versions, so that's not really possible without enabling the option in the management console to allow deletes. If you want to manage multiple buckets you certainly can. But I would just keep in mind that there may be bucket # limitations with the cloud vendor you're using. And you may want to plan for contingencies if you get close to reaching that limit.

Can you clarify if you're trying to do this from the management console or from the agent. Also please post an example of the format you're using for entering the information and whether or not you're supplying credentials.

I'd recommend using different encryption passwords for each customer and using a single bucket if possible. I don't think there's any reason to have to manage tens or hundreds of different buckets especially in light of bucket number limitations by many storage providers. If you're looking to make sure that no one can access the data then encrypting even using the same password would be sufficient, but if you're really concerned you can use different passwords for each customer. Presumably you're keeping those passwords safe and away from customers hands and only you the MSP knows them.