Venting frustrations

[swilsonbsb]

Since it seems I can't just send a feature request or comment in to a rep (I keep being told to post here instead), here is my vent about frustrations after about 5 months using the product.

1. Failed to merge full backup file Error. Support is going to work with me to resolve my current problem (01877933), but this keeps happening. It has happened to me at least 5 times and I have no idea (nor can any support person tell me) why it keeps happening. In addition to that, the error message doesn't tell me WHICH file it is having trouble merging. If it would at least tell me that, then maybe I could try to address the issue every time it happens myself. I use per-VM files so the file name will tell me which VM I have to start backups over for, yet again. The solution each time seems to be deleting all the incremental backups and starting the chain over again from the last full. This is getting VERY tiresome.

2. Backup copy job logic. So far, about 2 or 3 times a month I get emails about a backup copy job or two failing because it ended up running longer than the copy interval. From what I can tell, when this happens, the copy job stops and then re-starts. I've used several other backup products and none of them lock the logic together for how often a backup copy should happen and how long it should take. Not to mention, the backup copy jobs in most of these cases seem to be copying just fine (the data is copied to the second location completely) but then some internal maintenance process kicks off and that's what causes the delay. A full copy merge or a health check are things I keep seeing and I don't know WHY those things are happening when they are. I have them scheduled for the weekends and end of months and I keep seeing them pop up at random times during the week. Also, I have gotten 3 different answers from 3 different techs in regards to how these copy jobs actually work - as in, when they start when they are sourced from a backup job. Copy jobs should kick off immediately following the completion of a backup job. And why in the hell would you stop a copy operation just to restart it because it took longer than you expected. Just finish the copy and let me know it's still running. Don't error out.

3. Formatting of email when errors occur. When there is an error, whoever designed the email template decided to put the error messages in the right-most cell in the table. The result is an email that is very hard to read. That table cell ends up one or two words wide and miles long making the email itself miles long and reading that information is quite painful. Solution: Add a new row in the table whenever there is an error so you can use the whole width of the email/table to display this information.

4. Times for tasks shown in the console and emails. Every time I try to research what happened when - it becomes a nightmare to bog through all the timestamps. For example, when a backup job triggers a health check, or merge, or GFS, or whatever isn't strictly a backup operation, there is no way to tell when that started. When a backup happens and takes 30 min, then a full merge kicks off and takes 4 hours, then a health check kicks off and takes 3 hours - the whole job shows as taking 7.5 hours but looking back on the history I can't tell WHAT took that long. The detail view doesn't show merge, health check, or GFS tasks and it doesn't show when each step started and finished. It tries to show a duration of a step, but when there are 20 steps in a chain you have to step back on each one to try to get back to the starting time, but even then it's hit or miss because some steps do not show their duration.


I keep hoping that some of these issues will finally go away, but they persist. It's possible that my backup design is causing problems, but I've asked about that multiple times and support says it's fine. It's possible there are clues in the deep logs that can solve these things, but support is only interested in fixing what is broken at the moment and moving on, not digging into WHY it keeps happening.

Right now I just wish that we wouldn't have committed to 3 years with this product. *sigh*

[Gostev]

I keep hoping that some of these issues will finally go away, but they persist. It's possible that my backup design is causing problems, but I've asked about that multiple times and support says it's fine. It's possible there are clues in the deep logs that can solve these things, but support is only interested in fixing what is broken at the moment and moving on, not digging into WHY it keeps happening.

As a matter of fact, these issues will not go away for as long as you keep accepting "the solution each time seems to be deleting all the incremental backups and starting the chain over again from the last full" from your support engineer - because in this case, R&D never gets to see, debug and fix the issue. I always ask my users to help me help you by not accepting such solutions from our support.

Thanks for your feedback re: potential reporting enhancements, I will keep them in mind for the future versions.

[swilsonbsb]

When you say 'keep accepting' I think you misunderstand how I've gotten to this point. I didn't recap all of my interaction with support and my rep but I'll summarize.

I open a case about the merge issue, support works on the issue for hours and kicks it up to senior tech. Senior tech works for hours and kicks it up to a database engineer. That database engineer finally gets me going after hours of manually editing the database. The next day, the same thing happens again and I delete the incrementals and start again. All told, several hours of conversation happened with 3 levels of tech including a database engineer who seemed to know this happens and indicated that everyone internally knows already. On THIS issue, I just did update 2 and have been told that this issue is finally addressed. We'll see.

For the other issues, I've emailed my rep several times. He says to open a case here in the forum. I've opened support cases, they shrug their shoulders about the email formatting. 3 different support people have told me 3 different stories about how backup copy jobs work. When I ask for changes to the system they say post in the forums. So that's what I'm doing.

I don't see how one post into the void would make it back to anyone in charge, but maybe I'll just put it on my calendar to make a new post every month until someone maybe possibly sees it...

[Gostev]

I open a case about the merge issue, support works on the issue for hours and kicks it up to senior tech. Senior tech works for hours and kicks it up to a database engineer. That database engineer finally gets me going after hours of manually editing the database. The next day, the same thing happens again and I delete the incrementals and start again. All told, several hours of conversation happened with 3 levels of tech including a database engineer who seemed to know this happens and indicated that everyone internally knows already. On THIS issue, I just did update 2 and have been told that this issue is finally addressed.

Perfect, that's exactly what I am talking about. This is the only way to ensure that the issue actually gets fixed permanently.

Small tip - you can also ask for bug ID once you get a confirmation from support that this is a known issue (or that it has been confirmed). This way, me and my team will be able to track the progress on the resolution for you. Also, this ensures there's no misunderstanding and everyone is talking about the same bug.

He says to open a case here in the forum.

Yes, that's the right way to submit enhancement requests, as it helps us track the priority based on the amount of similar requests, so thanks for posting.

[swilsonbsb]

Well knowing that a VP of product management is reading this does at least give me some solace. Posting in a forum feels like shouting into the void sometimes.

Two more frustrations:

The design decision of using the NUMBER of restore points versus the TIMEFRAME of the restore points is different (and worse in my opinion) than other systems that use time as the retention variable (i.e. keep backup data for 90 days, versus keep 90 restore points). A specific problem with using COUNT versus TIME is that say my overall backup design is that I want to keep one week's worth of backups granular for daily restores and then past that I go to a GFS plan. Well, how many restore points do I keep? I back up every day except Sunday, so I should keep 6 restore points. Except if I run an extra backup one day before a big upgrade, then all of a sudden I don't have a week because I have 2 restore points for one calendar day and so my oldest point gets bumped up by a day. While admittedly this isn't a huge deal or a common occurrence (but it happened this past week for me), it adds to the inconsistency that I'm seeing with Veeam. No matter how I have things set up, I can't say for sure that I will always have a week's worth of history in the immediate restore points. I could end up with only a few days worth of restore points under the right circumstances like testing a new backup setting or multiple upgrades in one day, or, or, or...

Not being able to put a GFS plan on a backup job means that I've had to create a backup job, then a copy job, then another copy job in order to satisfy my backup requirements. Those requirements are to have the SAME backup data at my production location and my offsite location, which doesn't seem complex to me. Because I can only specify a simple count of restore points for backup jobs (and I don't want a 90 file chain), I've had to do the double copy thing and that feels strange and prone to breaking. Without the double copy though I'm only able to do a very long chain of restore points in the backup job and then a GFS with my offsite copy job - and that ends up with vastly different set of data at each location (with the production site having a much larger data footprint than needed).