Feature Request - Read and write on the same backup chain

[DaveWatkins]

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.]

Hi Dave,

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

[DaveWatkins]

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]

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]

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]

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