Replies posted by ddomask
@ddomask just for testing purposes / knowledge. Yeah, what you say is right, but in a case of disaster recovery with what I use to start a piece of hardware shouldn’t matter. If we think about a backup file, it should be not related to OS. VBR confirm it works. I even found this thread on forum https://forums.veeam.com/veeam-agent-for-windows-f33/restore-from-encrypted-backup-unsupported-vbm-format-t73026.html Hey, it’s not a criticism to Veeam, I absolutely love it, but I don’t get why this limitation exists. But it does matter :) As you see. Backup data isn’t just “dumb” data, there’s a lot of OS specific metadata to tell us how to restore the blocks. That Thread doesn’t really tell me it works tbh, it’s just about the same error message. Instant Recovery works because we process the backup metadata and depending on the OS (and it’s configuration), we do a lot of black magic to make it work ;)Not taking any of it as a criticism, just trying to get you in the right direction :) So y
Hi @marcofabbri , Do I get it right you made a Windows based Recovery Media and are trying to use it to recovery a Linux backup?This won’t work; the Windows Recovery Media (WRM) is based on the Windows Recovery Environment, and as is such it doesn’t know what to do with Linux as it’s basically Windows PRE (Pre-recovery environment).Similarly, Linux backups use a specific linux boot appliance (probably wrong word but close enough) and it expects to have Linux.As far as I know it’s not a cross-recovery boot loader, so you should just from the Veeam Server make a linux recovery media and you’ll be good to go.Is the goal just to reduce the number of Recovery Media to maintain?
All, by default both Veeam and all public cloud providers use TLS 1.2 for communication; unless you manually set a lower level on the Azure (or AWS/whatever) side, it will be using TLS1.2 out of the box without a need to change anything. I would not recommend changing AzureConcurrentTaskLimit unless specified by Support. @Anandu if the issue is intermittent (that is, it runs fine for awhile then randomly throws this), please open a Support case and refer to issue 350539. You must include a log export from the VBR server also: https://veeam.com/kb1832. Use the 3rd option and select the VBR server, and upload the logs to the case for review.
I know just 2 situations where I needed direct SQL access to get the work done. One for getting the absolute path of backup files located in SOBR, the second for querying backup files on tape. For all other I highly recommend not to use any direct SQL access - especially for changing something. This is something Veeam support should do. This one isn’t entirely true, but I agree it’s not clear if you don’t know how SOBR paths works. SOBR uses relative paths as a given backup file may be on any extent; to avoid constant lookups to the infra/DB, the paths are stored as relative. I’ll share what’s in my private notes document for engineers and an example:#Storage Paths (Backup paths)* Scale-out Repositories (SOBR) and non-SOBR repos have different paths * Non-SOBR use full path on system and can be retrieved with just the path for the Storage Object * SOBR uses relative paths for the Storage and need to be constructed with: * Extent.GetPath() * MetaPath property† * Storage Nam
Just my input as a support person...I don’t.Seriously, feeds and aggregators just add another task list which I don’t need :) When we understand how technology tends to work and when you understand the basics behind the scenes of most tech, it’s a lot easier to stay on top of it as then new tech announcements are less about the technology, and more about the nuances and how it differs from the original project/RFC/whatever.We deal with this in Support a ton as every environment we face is truly unique; one case entire environment is a few Windows/Linux servers backed up by agents. Next case you’re dealing with a VMware environment across 4 continents and 2000 VMs in the job and some custom built storage array to cram it all into.There’s just too much to constantly chase every new article or tech announcement (and in my opinion, most such announcements are too “fluffy” to be of use anyways) When I was on Support Tier 1, I ingested the information in the following way:First give myself
@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.