Replies posted by ddomask
@omfkIn terms of Reverse Incremental vs (Forever) Forward Incremental, your concerns are always:Performance: Reverse incremental has highest performance requirements on the target repository Secondary Features as Joe mentioned like Hardened Repositories and offloadingIn the past, Reverse was the way to go for fast restores because the most recent point was always a full, but a lot has changed with the restore engine in past years, and now you ought get pretty good performance regardless of the restore mode.If restore performance is your only consideration, I’d strongly weigh that (now less impactful) benefit against the benefits of hardened repositories, the performance cost on the target repository for backups, and simplicity of offloads. * Harden (immutable) backup chains must be Forward Incremental: https://helpcenter.veeam.com/docs/backup/vsphere/hardened_repository_limitations.html?ver=110#limitations-for-repositories* Move mode will never “move” the full backup from Performance t
This part of the script used to work since the approxsizestring use to report the size in vCenter, and if the machine isn’t there, it would report a size of 0GB, now it’s reporting the VM size when it was added to the job. Anyone have a good way to automatically remove a VM from a job when the VM size is 0 (or any other programmatic method that can be nailed down in a script)? Old thread but in fact this is not quite accurate @7Ryan7 You original code likely still works, it’s just that Veeam does a lot of caching of data from the Vmware hierarchy to avoid constantly spamming the vCenter; CObjectinJob objects aren’t updated as fast until it’s absolutely necessary to poll them, so my guess is your script does work, it just isn’t immediate. Likely, if you just let the script run, it will “garbage collect” as expected once the job runs and updates the object after realizing it’s gone.Is it essential to prune the jobs immediately for some reason?If it is, then vNote’s solution is t
Has anybody have an idea if the number of files in a repository can be shown as well? I have been looking for this some time now but I have not yet found it. regards Steven Do you mean like the count of backup files @StevenA ?CBackupRepository Objects have the GetBackups() method, and CBackup objects have the GetAllChildrenStorages() method.You can string these together like so: PS C:\Users\Administrator> $repo.GetBackups().GetAllChildrenStorages().count70Remove the .count call and you will get an array of Storages (backup files) on a repository.Note that this is only about what Veeam is aware of; that is, if there are orphaned points not visible in the Veeam UI, this method will not help (no Veeam powershell cmdlet will).
Hi @ddomask ! Thanks for your input! The original script, this is based on, you can find here (link is also in first paragraph of this post): https://www.experts-exchange.com/articles/27059/A-PowerShell-script-to-measure-VM-data-change-rates-using-Changed-Block-Tracking-CBT.html As I adapted it, I checked the VMware documentation how CBT queries should be implemented. And the script seems to be correct! Does not mean there could be a mistake or rounding-differences. I tested my script in a lab, not in real world. Aha, I appreciate that! Just as I do comparisons from the same ChangeID between what a Veeam job pulls and the script pulls, the script usually does come up short. It’s “closeenough.png” that it’s convincing (I wrote several modules for that can be quickly imported and used as a test in the field), but the discrepancy of sometimes 4+ GB is too much for my taste and I’ve not yet gotten to the bottom of where the difference is. It’s a “when it’s quiet” project so I’ll update if
This script is interesting for sure, but I’ve been testing it (before I even saw this post) and I find that it comes up a bit short compared to Veeam. I’ve seen the original script that I believe this is based on, an I’m not convinced the math in the DoWhile is quite right.Maybe you've done some comparisons with lab tests of an incremental run right after? Seems it’s always off a pretty decent factor. Maybe it’s related to snapshot consolidation after the script runs, but it’s kind of hard to rely on given how far out it really is from a Veeam Incremental run, so I am more inclined it’s an maths issue. Did you test anything similar out on Hyper-V to see if similar data could be extracted? HV you need to go differently to attack it. $wmiclass = Get-WmiObject -Class "Msvm_ImageManagementService" -Namespace "root\virtualization\v2"#GetVirtualDiskChanges() is a method for ImageManagementService, so set this first for ease of accessGetVirtualDiskChanges accepts a similar set of parameters
Login to the community
Log in with your Veeam account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.