deleting backups from the agent has been disabled in the latest versions — David Gugick

That is a nice safety feature. Can I purge backups from the management console, or I would have to enable the client side deletions if I need to free up space? I'll have to look around.

I get exactly what you're saying about buckets. It doesn't seem like there's really much of any gain by using more than one. Like I said earlier, I only have one bucket in B2. It's with Wasabi where I was starting to organize (add) buckets.

I always use different encryption passwords, and different passwords for each user. Yes, I keep that info secured.

I don't have a link to the original reddit thread, but the question was could user 1 maliciously (or via malware) navigate outside of their folder in the bucket, and possibly delete data for user 2 (or the all the contents of the bucket). Seems very unlikely, but I think that's where the idea 1 bucket per customer came from. Possibly some form of isolating customer data from other customers. I don't know if there's any merit to that, but I think that was the logic of multiple buckets.

Ah yes, PST files... Other big files. I've gotten so used to setting up image based jobs, that I kind of forgot how to do file based. So, no real benefit to going block level for desktop files. I guess it has the potential to give you a few more versions, but no real reason to turn it on if I'm not dealing with large files.

That option will only kick in if, for example, you stopped backing up that computer and then started again more than 90 days from the last backup. — David Gugick

I don't follow this part. I would only see older than 90 day images if I stopped backups and restarted them?

In order to delete the oldest backup set while keeping 90 days, we need to start the 4th backup set on Day 91 and run it through its 30 days of incremental backups. On the day the 5th set starts, the oldest set (full + incrementals) will all be older than 90 days and can safely be removed. So expect 4 full backup sets in storage eventually (4 fulls + 30 days of incremental backups for each set). — David Gugick

This is what I see on my servers with 90 day retention. The oldest full and it's blocks go away as soon as the 5th full job runs.

OK, so browsing my oldest full image in my job with 90 day retention, and keep last version on (I'm almost positive this has been on, but I may have turned it off / on a few time since posting about it here)... I can't find a windows update log file that goes back before mid February. It doesn't seem like the keep last version does what I expect. I feel like understand how this works just fine with a file level job. However, with block level the blocks and incrementals are connected so it makes it confusing. If it hadn't been on that would explain this. It's on now, so when the full runs this weekend I'm assuming that the Marrch full wouldn't be allowed to be purged because the log files I'm looking at are unique named and windows auto purges them. There a no logs with dates in Feb if I look at that folder. I'm using the Windows Update log files because I know there is a lot of turn over there.

In the 90 day scenario you said I could end up with 90 versions of a file. That's what I see when I browse my full image backups, as if restoring the whole VM. So, that makes sense. If I change my job to 90 day retention but only 3 versions, then what will the result be? Does the job purge blocks that match up with files that are the versions older than 3?

So, I'm going to try the versions settings on a different server to see what happens. I'm going to set it for 90 days, keep last version, and no more than 3 or 5 versions of a file. I'm still not sure how that would apply to the choices for restoring the entire VM. At this point I guess I have to experiment and see what I get.

What did you come up with upon reviewing my long posts? :lol:

Thanks! I appreciate it!

I know that image backups are different, but the settings are the same for retention. That's where I'm getting confused. I thought setting the file version age to 90 would give me a nice spread of files. Most of the time you only need the most recent version of a file, and occasionally one previous version if they save over top of something

I assumed with 90 day file version age I'd have a minimum of the file at 3 points in time: month 1, 2, and 3's full backups. Now that you got me thinking, I guess without versioning turned on the full backups will contains 3 copies of the same file if it hadn't changed in the last 90 days. I think that's generally OK. I think that I thought the daily block jobs would give me more versions.

Realistically, if I tell my customer 90 day retention on their backup I want to be able to grab the file from the last 90 days. If they deleted it 180 days ago, that's too bad (if we agreed to 90). If I had "always keep the last version" on will that force an old blocks/full to stay around forever? I don't think I've seen that, maybe because people don't generally delete files as much as just adding more.

The reason I haven't messed with versions on block level might be my misunderstanding: If I have a file that changes daily and the full job runs every 30 days, and daily block level jobs... Wouldn't I be able to have 30 versions of that same file? Or without versions are we deleting the ones in the previous blocks? Maybe in this scenario keeping 3 version of the file will actually make the jobs smaller?

Can you provide a suggested settings for a block level job? for 30 or 90 days retention? I feel like I'm still fuzzy, although I've never had issues with the settings previously I think I had last version on, but I'm confused about that warning message after what tech support said about it.

I missed that they escalated the ticket to development. So, maybe they saw something in the logs.

Just to update here...
Modified the timing on my test system. Full syn works when there isn't a scheduling conflict. There needs to be a proper queuing method here or something that gives full backups higher priority than block levels. Trying to guess when jobs will finish is a pain. Maybe the easy solution is to schedule the monthly full syn to run 5 minutes before the daily job. That would at least make the less important job get skipped vs the full. I still feel like I lacked proper notification of the missed full job,

I'm saying the full syn doesn't run because the local daily block level job in the chain is running. I think it will work as long as I schedule the full syn for a different time than the nightly local image.

Are you saying that the syn full job scheduled for 11 PM should work? It does not. I see errors about it not being able to run because another image job is already running. I think I have to choose a different time slot for it.

Awesome info. I think I figured it out not long after posting the original message.

Full local image: First Sunday at 11:00PM
Daily local image: 11:00pm
Wasabi image: chained to previous job
Wasabi full: Second Sunday at 11:00 PM

As far as I can tell the Wasabi full syn has never run! I don't remember seeing it as a missed job. I wonder if that's because the job itself is unscheduled except for the full? Either I missed it or I wasn't properly notified. i'm going to have to see if I can find old emails. For some reason I thought the second image job would queue up. Would you think notifications work properly for that chained job? Ugh, this wouldn't have happened if we had hybrids (w/ syn) as an option.

So, why run the Wasabi full image weekly instead of monthly? Also, I don't really need 90 days of backups, but I wanted to do whatever makes most sense because wasabi charges for 90 days whether you keep it or delete it.

Has this been resolved? What'd the current method for rotating drives on v 6.0.0.245?

Well, it finished. 289.8GB in 2.23:17:41. I throttled it today and no one seemed to notice I stole half the upload. I would love to see the job complete in about half that time. However, a synthetic full would probably solve my issues. The first incremental ran tonight as well with 2.72 GB in 58:59. That's reasonable for nightly backups.

As for the sending files only to the cloud... That has been our default configuration up until rolling CBB & Hyper-V. On physical servers I always would set them up backing up files to the cloud, and full image jobs locally. We used Rbackup back in the day, and ran our own server. It didn't have a reasonable option for a full server - if I remember. So we often used Windows Server Backup too - - no monitoring. However, I much prefer using CBB for the local backup so that I'm confident of the local full image and the cloud backup.

I think I'm going to run CBB on the Hyper-V Host for right now... And hope that very soon we have synth full options or more granular selection options. I'd really appreciate those features. I don't know how de-dupe fits into the plans but not backing up Windows system files multiple times would also save time / space.

Thanks for all your input!

I did another speed test and the upload came in at 10 Mbps. I have a hybrid hyper-v job running since Friday at 8 PM (2 days 15 hrs). It's at 91% of the last 264 GB VHDX file. It doesn't seem too bad to have a job run for 72 hours once a month. What do you think?

Are the enhanced features for Hyper-V coming soon? Either the ability to select / exclude files or full synthetic jobs?

Otherwise I might use CBB VM edition for backup to disk, and install CBB Bare Metal on the guest file server for a files only > cloud job. As for the DC I think a backup of it from the host level to disk should cover us pretty well.

Yes, I'm stuck between a rock and a hard place here. I hate to have to buy extra licenses. I'm very disappointed to find out that the CBB VM edition allows more granular file selection / exclusion on VMware. I hope this feature comes to Hyper-V soon.

What are your thoughts on backing up those files from the Host serve by UNC? \\GuestVM\Shared

Yes, I'm already using the MBS / MSP edition. Sorry for not being clear.

I want to backup the VM for sure, especially since the speed of a VM restore is one of the strong points of going virtual. I certainly want to back AD as well. Right now I'm doing a local backup to a USB drive attached to the host. I'm not backing up anything to cloud storage at this point on the new server. It's only been live for a few days.

If I install CBB on each VM then I assume I'll need more licenses? Or does the VM version of CBB come with extra licences for the VMs for file level? Isn't there any way to do a file level backup of a VM from the Hyper-V host running CBB?

I certainly could use Windows server backup on the hyper-v host, but I lose my monitoing and management that I get with CBB. I would like to keep everything with CBB so I know what's going on. It's way more likely to have a failed backup than catastrophic failure where I would need something from the cloud restored. The monitoring is just as valuable as the cloud portion... If not more valuable.

I thought Wasabi synthetic full was only available for physical machines and non-hybrid backup jobs.

Yes, I was thinking of how Windows Server Backup doesn't treat a NAS the same as a USB HDD. How you lose the differentials or whatever... But in my experience CBB makes no distinction between a local or NAS destination. I was just double checking.

Sorry, I'm referring to a target destination for an image, file, or hybrid job.

So, in terms of storage used - it seem like multiple synthetic full backups won't use the same amount of storage as say 3 x full image backups. So, we're always building on the 1st full?

I'm going to have to play around with my test machine, and take note of storage amounts used in my Wasabi bucket. It sure seems like the each monthly shouldn't be much larger than a block level - if I'm understanding.