• Image Backups of Virtual Servers
    Thanks David. We did a test of Option #4 and it worked great.
  • Time Discrepancies and Overdue Backups
    This has been happening to us, particularly for SQL Backup Plans, for over a year.
    If I open the plan and save it, the overdue goes away.
  • Status of Backblaze Synthetic Backups
    Thanks for the update. We don't have a lot of Image Backups as we have moved to Hyper-V virtuals for the bulk of our clients. But I just moved all of the Image/VHDx backups from Standard Backblaze to BB S3 so that I can use Cloudberry Explorer to manage it (vs the awful Backblaze Web Portal that takes several minutes to load the list of files).
    On an semi-related note, how is the new Backup format going in the Standalone product?
  • Optimal Retention Policy for Wasabi
    Another option is to utilize Backblaze S3 Compatible storage. Cost is $.005 per GB per month and there is no minimum retention period. Since we only keep one monthly version of images/HyperV Vhdx files in the Cloud (vs. 90 days for files), Backblaze is ideal. We keep local Daily image/VHDx copies, and consider the monthly VHDx/Image to be a Disaster recovery solution.
  • Interrupted Image based backup: Graceful continue?
    I did not know this was a feature. Can you explain how it works technically? The article you referenced is light on details.
  • Size Mismatch Between MSP Space Used and Amazon AWS
    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.
  • Unfinished Large Files
    Best way to see what unfinished files you have is to go to the Backblaze portal. ( 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).
  • Wasabi Data Deletion Charges
    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.
  • Portal Usage - Backup Size
    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.
  • How to Ensure Local Backups While Cloud Backup Runs
    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.
    • 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
  • How to Ensure Local Backups While Cloud Backup Runs
    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.
  • Problem trying to configure backup for g suite
    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.
  • Files and folders were skipped during backup, error 1603
    It is a very recently - added message. Been using SW for 6 years and it showed up just this year
  • Files and folders were skipped during backup, error 1603
    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.
  • Associating S3 bucket with user
    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.
  • Fast NTFS Scan Improvements?
    Thanks for the quick reply. Now if only we could enable Fast Scan via the MBS portal.
  • Backup Storage Question
    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.
  • Backup Storage Question
    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.
  • Stop / Start Initial Backup - Bandwidth Adjustments
    Also, The bandwidth throttling recognizes if you have multiple plans running simultaneously and splits the available bandwith between them.
  • Unfinished Large Files
    That works. Thanks

Steve Putnam

Start FollowingSend a Message