David,
I did not know this was a feature. Can you explain how it works technically? The article you referenced is light on details.

Alternative approach:
We do not allow deletion of storage at the client MSP360 console as a hacker can delete your backups when installing ransomware. It is a setting in the Advanced Branding. It actually happened to one of our clients - the hacker installed ransomware and deleted backups, but fortunately they failed to remove all THREE of our backup copies (One Local, two cloud). After dodging that howitzer, we disabled deleteion of backups from the console and instead use Cloudberry Explorer (or the Backblaze Portal), then we run a repository sync on the client to update the storage usage.
Yes the repository syncs take a long time, and unfortunately no backups can run until repo syncs are complete.
It would be great to separate the repo syncs such that for example, we could still run a local backup while the Amazon repository sync is in process.
And if all that seems like too much trouble, and you want to use the console to delete backups as David suggest, please be sure that you have an MBS console password set , including CLI, and that it is different than the server password.

Best way to see what unfinished files you have is to go to the Backblaze portal. (https://secure.backblaze.com/b2_buckets.htm) and it will list any unfinished files. I then just go to that particular folder and delete the files that show 0 bytes.
Ultimately it would be great to have that done automatically, but for now, it is worth a biut of manual effort to get the savings that Backblaze affords (without the 90-day minimum that Wasabi has).

Or you could send the backups to Backblaze, which has no minimum retention period and costs only $5.00 per TB per month. While we keep our data file backups for 90 days, we run new Image/VHDx backups to the cloud each month and only keep one copy in the Cloud.

Yes Backblaze does charge $0.01 cent per GB for downloads (vs Wasabi's free downloads), but we only do large restores a few times a year - a 200GB Image download costs a whopping $2.00.

Starting with the easy one - The 6 files are the individual components of the image. If you look at the backup history detail and select "files" you will see that they are the drive partitions.
And yes the numbers are different depending on where you look.
There are at least three different size metrics , One is the actual sum of the partitions. Another is the used size of the partitions, and the third is the actual compressed uploaded size of those partitions. In your case, I would expect the actual backed up size to be 90-100GB (110 GB minus compression) , not 4GB. The only way it would be 4GB is if you ran a block level incremental backup after the full image backup completed.
If the 4GB is the actual full image then the only explanation is that you excluded a large number of folders from the image.

What is the internet upload speed of your client? We require our clients to have at least 8 mbps upload speed in order for us to provide Image backups to the cloud. 8 mbps (1 MBps) translates to roughly 3GB of backup per hour so a 62GB upload could be done in ~20 hours. A client with 2TB of data and/or image Cloud backups cannot possibly be supported if they have DSL or a 3mbps upstream speed.
For one large client, it took us two weeks to finish the initial upload of 2TB to the Cloud over a 15mbps upstream connection, but after the initial upload was complete, the nightly block level file changes amounted to no more than 10GB or so, usually less.
We first setup a local flle backup to an external 5TB hard drive and that cranked along at 20MB per second - that runs every night so at least they were getting local backups during the two weeks that the cloud initial upload was running.
For this client we actually run two Cloud file/data backups in addition to the local backup each night. One Cloud Backup goes to Amazon One Zone IA, and the other goes to Google Nearline. We schedule them to run at different times each night, and they finish in 1-2 hours each.
Summary:

• To provide Disaster Recovery Images and to backup that much data, we would insist on at least 8mbps upstream.
• Once the client gets a faster connection, you should run the Local Backup of both the 2TB and the Image (minus data) and setup the File backup to run nightly. Schedule the Local Image backup to run, say, Mon - Thurs block level and a Full on Friday night.
• Start the 2TB Initial Cloud File backup ( at 1 MBps it will still take ~30 days to complete - at 2 MBps = ~15 days)
• Once the Initial 2TB upload is complete, schedule the File/Data Cloud Backup to run each night
• Run the (62 GB) Image backup to the Cloud. Start it on Saturday morning and it should complete easily before Monday morning.
• Setup the Monthly Cloud Image plan to run on the First Saturday of the month, and if you want, run weekly block level image backups on the other weekends.

Let me know how you make out with your client. I am happy to assist in designing your backup plans.
- Steve

We too have some large images, so we have adopted the following approach:

• We do both Image and file backups.
• We exclude the data folders from the image backups to keep the images to a manageable size (The OS and App installs primarily)
• We run separate file data backup plans nightly - one to the local drive and another plan to the Cloud
• We run the Full image (with data excluded) to the Local drive each Saturday, with incremental image backups each weeknight.
• Once per month we run an image backup to the Cloud. If the image is still too large to get done in a weekend, we run a monthly incremental and periodically do the Full Image backups (over three day weekends usually)

This way, the actual data is backed up every day to both Cloud and Local drive, and the Local image is only a few days old in the worst case. For DR, having an up-to-one-month-old image is fine for our situation - we can apply any program/OS updates after recovery.
The key principle is that separating the OS and Apps image backups from the data backups allows you to run the data backups every night to both locations regardless of how often and for how long the Image backups run.

David - We are trying to test the Google App Backup but are getting the same error message. Temproarily disabled. Sent in a ticket, but so dfar no response. Can you send instructions?
Steve P.

It is a very recently - added message. Been using SW for 6 years and it showed up just this year

David,
Any idea why this “feature” was added”? I hate it. I know which folders I skipped and why. I am constantly getting calls from clients because the daily status email includes this information which scares them. Include it in the plan settings spreadsheet if you must, but please take it out of the back up detail history and off the email notifications and plan statuses.

Go to the users tab and click on users. Find the user you want and click on the green icon on the left. It has the MBS prefix that you can then find in Cloudberry Explorer.

Thanks for the quick reply. Now if only we could enable Fast Scan via the MBS portal.

I recently switched all image and VHDx Cloud backups to BackBlaze B2 storage. Once per month is adequate for most clients, though some ( who tend to make app changes more frequently) get weekly image/ VHDx backups.
The thing that is not discussed is that you do not need the VM version of MSP 360 to do HYPERV Backups/ recovery. Simply backing up the VHDx files and the .xml files is sufficient to provide for a Disaster Recovery.
For those with very slow upload speeds, I tend to do fulls two-three times per year and incrementals each month, and am waiting for the synthetic backup for BackBlaze to be released in the MBS code.

We do monthly full backups for all of our file-based backups, since only files that get changed during he month are re-uploaded in full during a "full" backup. These tend to be Quickbooks files, psts, and operational spreadsheets that change frequently during the month. Still, they represent only a small percentage of the overall files that change, so fulls once a month is fine.

Also, The bandwidth throttling recognizes if you have multiple plans running simultaneously and splits the available bandwith between them.

That works. Thanks

Has there been any development on this on the MSP360 side?
Regretting switching to Backblaze as I’m getting charged for unfinished file uploads. Would consider Wasabi, but required 90 day retention is too much for Image backups, as we do once-per-month fulls, and only store one.

I have sent in many sets of logs to Ticket #293616 - Just got another one - that makes 11 different clients. Seems to get hung up on one file - thought it was just large files but the most recent failure waa on a file that is under 1MB. Hoping that someone can fill me in on what is going on.

Our approach to client backup/ recovery using MSP360 MBS is a bit different, and is based on separating data file recovery from OS/ system recovery.
For the data files we use file level backup to a local USB drive and to the Cloud. The initial Cloud backup takes a long time, but after that, only files that have been added or modified are uploaded, typically a very small amount of data. The retention period for versions is usually 90 days. We run “full” file backups one a week, which are only marginally bigger than a block level backup.

For operational OS/System Recovery ( meaning any issue that requires a reload), we do daily or weekly Image backups of the C: Drive to the local USB drive, but exclude the folders/drives that contain the data files as they are backed up at the file level.

For true Disaster Recovery ( when the server PC and the local USB drive are unusable) we run monthly Full Image backups to the Cloud, again excluding the data folders.
These Image Backups typically range from 25GB to 100GB or so and we keep two month’s worth in the Cloud.
We do not see the need for ( or have the bandwidth for) a daily Cloud Image backup, or even weekly for most customers whose OS and apps do not change often.
To recover we do a Bare Metal image recovery from the USB or Cloud, then restore the files to the most recent backup.
Other notes
At 30mbps, you should be able to upload 10-13GB per hour, meaning a 50 GB system image would
take under 5 hours to upload to the Cloud. And most recoveries can utilize the local image backup.
We have a customer with 3 TB of data and have no trouble running the local and file cloud backups each night and the OS images on the weekends.
We employ this same approach for our clients with HYper-V instances. We try to create separate VHDx files for the data drive so that we can exclude them.
I realize that other MSP’s have different approaches and requirements, but this strategy has worked well for the 60 servers that we support.
I would be happy to discuss the details of different strategies with you either in this forum or offline.

It is for this reason that I keep the new version in the sandbox and leave the old version as public until a new version comes out. I update using the sandbox build and can roll back if necessary using the public build.