I was told there were some upcoming news regarding job prioritizing, but that was two years ago, so I don't know if that is still going to happen.
You can however set up a bunch of drives as read-only, hence they will not be used by your backup jobs and they won't take any parallelism unless there is a restore coming around. You could set up one drive per storage node or so, and that will probably be fairly easy when using a VTL. You can use target sessions and max parallelism to limit number of backup jobs.
In theory read operation should have higher priority and in past Legato did promise that to deliver. I have't seen that anywhere mentioned, but I do remember someone from EMC said this would be the case with 7.2.x.
I use VTL and since with VTL you are not limited by number of drives I never went into this problem.
If this would not be in place, I suspect EMC might not be in mood to implement it so far given the disk/dedupe momentum they are in at the moment (where they could easily use this - and they use - as one of disk advantages over tape).
Depending on the number of pools, have you limited the pool parallelism? If the max number of concurrently used pools has a total max pool parallelism less than the server parallelism it should reserve something for restores.
I know I could configure the resources so that there is always some resources available to do a restore.
But that would impact the backup performance, and we really need all the throughput we can get for backups.
But in the case of restore, I think it's only fair that the backups would take a lower priority to allow the restore to start at the next available slot. But instead, the backups that are waiting in the queue before the restore, get attention first and the restore has to wait.
R_Friberg
34 Posts
0
August 10th, 2010 12:00
Hi,
I was told there were some upcoming news regarding job prioritizing, but that was two years ago, so I don't know if that is still going to happen.
You can however set up a bunch of drives as read-only, hence they will not be used by your backup jobs and they won't take any parallelism unless there is a restore coming around. You could set up one drive per storage node or so, and that will probably be fairly easy when using a VTL. You can use target sessions and max parallelism to limit number of backup jobs.
/Rickard
ble1
4 Operator
•
14.4K Posts
0
August 23rd, 2010 07:00
In theory read operation should have higher priority and in past Legato did promise that to deliver. I have't seen that anywhere mentioned, but I do remember someone from EMC said this would be the case with 7.2.x.
I use VTL and since with VTL you are not limited by number of drives I never went into this problem.
If this would not be in place, I suspect EMC might not be in mood to implement it so far given the disk/dedupe momentum they are in at the moment (where they could easily use this - and they use - as one of disk advantages over tape).
MikeToo1
38 Posts
0
September 14th, 2010 13:00
Depending on the number of pools, have you limited the pool parallelism? If the max number of concurrently used pools has a total max pool parallelism less than the server parallelism it should reserve something for restores.
Please let me know if you try it.
joka2
144 Posts
0
September 16th, 2010 04:00
I know I could configure the resources so that there is always some resources available to do a restore.
But that would impact the backup performance, and we really need all the throughput we can get for backups.
But in the case of restore, I think it's only fair that the backups would take a lower priority to allow the restore to start at the next available slot. But instead, the backups that are waiting in the queue before the restore, get attention first and the restore has to wait.
Johannes