Comprehensive data protection for all workloads
Post Reply
DaveWatkins
Expert
Posts: 345
Liked: 91 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Feature Request - Read and write on the same backup chain

Post by DaveWatkins » May 09, 2016 8:54 pm

Hi

What I'd like to request is being able to perform multiple read operations, or a read and a write operation on a backup chain at the same time with more granular locking and better failure scenario's.

For example, I should be able to run a Health Check, and a Backup to Tape at the same time from the same source job, both are read operations as far as the stored data is concerned. The ideal would be to be able to write to tape as a new backup is being created. As far as I understand from a technical perspective this should be possible, before the backup to tape job starts (this could be a copy job just as easily) it makes a map if the chunks it wants to put to tape/copy, similar to how a "virtual full" map is made when backing up to tape, then these chunks are tracked even as they are moved by the backup job that's writing new data into the chain and pulled from the appropriate place.

Even being able to have multiple operations going for VM's in the same job when using per-VM backup chains would be useful, but not nearly so useful as the above.

Thanks

Dima P.
Product Manager
Posts: 10109
Liked: 813 times
Joined: Feb 04, 2013 2:07 pm
Full Name: Dmitry Popov
Location: Prague
Contact:

Re: Feature Request - Read and write on the same backup chai

Post by Dima P. » May 09, 2016 10:05 pm

Hi Dave,

I hope another feature will help you to deal with disk and tape jobs running at the same time.

DaveWatkins
Expert
Posts: 345
Liked: 91 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Feature Request - Read and write on the same backup chai

Post by DaveWatkins » May 09, 2016 10:22 pm

That looks like only a partial fix at best and while it would be nice, the thing that actually got me thinking about this was a Health Check on our mail servers job that took over 24 hours to complete, thereby skipping the next days backup. I started wondering why a health check should really stop any job from happening since it's only reading data (unless it finds an issue).

Maybe this dovetails into why health checks take so long anyway. Our storage wasn't anywhere near it's performance limits while this health check was going on and neither was the repository server that presents it, there is about 5TB of data in that job but it's on a SAN with 40 x 7200 RPM spindles. Is there some sort of artificial limit on Health Check speed so as not to impact other jobs perhaps?

foggy
Veeam Software
Posts: 17931
Liked: 1512 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Feature Request - Read and write on the same backup chai

Post by foggy » May 17, 2016 4:17 pm

There's no artificial throttling, health check performance is mostly defined by the backup size and by what the storage itself can provide in terms of the read speed.

DaveWatkins
Expert
Posts: 345
Liked: 91 times
Joined: Dec 13, 2015 11:33 pm
Contact:

Re: Feature Request - Read and write on the same backup chai

Post by DaveWatkins » May 17, 2016 8:05 pm

Maybe that's a prime place for some optimization in a future version then. Assuming a normal health check just reads through the backup chain in chunks and CRC's the data against CRC's generated during the backup there is no reason for it to take as long as it does. The 40 spindles I mentioned above are in a RAID10 and I max out the dual 4Gb FC ports on this repo server before I max out the SAN. Neither of those was even close to happening and CPU usage on the repo was between 0 and 5%

foggy
Veeam Software
Posts: 17931
Liked: 1512 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Feature Request - Read and write on the same backup chai

Post by foggy » May 18, 2016 2:23 pm

Yes, I admit there's a place for some future improvements in this regard. Thanks for the feedback.

Post Reply

Who is online

Users browsing this forum: doddsyuk, sherzig, soehl, ssimakov and 60 guests