In earlier Veem versions the VeeamZip filename exactly matches the name of the backup job. For example "Management_VM_2016-04-12T-174514.vbk".
In Veeam 9.0.0.1491 the naming is strange:
1. The filename contains spaces, what is not so nice.
2. The time at the end of the filename does not match the one in the Backup Job. Now we have to guess which filename belongs to which job.
Why did you change this? It was much better in the earlier versions.
1. The filename is based on the name of the VM so if this is called "Management VM" then the space is normal.
2. The timestamp you see in the job title within the Veeam GUI is the timestamp where the job starts however the timestamp in the filename is the one when the VM is being processed.
Niels is spot on. v8 didn't have per-VM chains and the timestamp in the name of the file reflected the overall job start time. Now, with per-VM chains, each VM backup file has its own timestamp based on the time it's processing has started.
I have tried v9 and v9.5, but there does not appear to be such an entry in the log. With these versions, how does a person tell what the filename is? And why was this information removed from later versions? (It never occurred to me that such basic information would be removed, so I installed 9.0 instead of 8.0 on a new server.)
Hello Craig and welcome to the community!
Reason of new naming logic is described above. Unfortunately there is no way to set a file name in UI.
Thanks!
I'm not objecting to the name of the file. The problem is that there is no way to tell what the filename is from the UI in v9 and v9.5! (Somebody decided to REMOVE this information from the log!)
Due to time constraints, I'm still using the free version. (I'm in the middle of a complete overhaul of our virtualization solution, and because of all those changes, I just use VeeamZIP for now.) Once the virtualization solution overhaul is complete, I'll be looking to upgrade to the paid version. I just wanted to make sure that I continued to use Veeam during this process so that I remained familiar with the product. But I wasn't impressed when something that I relied on (VeeamZIP) got broken intentionally! I don't like to commit to a product when something like that occurs without anybody saying to themselves, "What happens to our customers if I remove this line from the log? How are they going to be able to tell what the VeeamZIP filename is?" The fact that nobody at Veeam thought about this doesn't give me a lot of confidence in Veeam going forward. (I am still appreciative of the fact that you will be adding this back in, and I will give Veeam another chance once this occurs, but it still has to factor into my thinking.)
