I agree with the below.? As soon as there is a file you don?t want the tape is likely to stop, rewind, then carry on from the file you do want.
?
Which backup software are you using and tape library.? There may be some tuning you can do to increase the buffers etc.
?
Andy
?
?
Our guys here have the following input:
?
?He is better off restoring to a restore folder and rsync?ing it. If the files are scattered on the tape it has to seek all over the place anyways, plus check the files and dates.
Also queuing restores can be difficult. We deal with the issue he has all the time. Where Presstore changes its mind half way and leaves a job hanging?.
?
?In response to the queuing issue, my experience has been that anything more than 3 restores trying to run at the same time will cause the robot to get distracted.
I have been starting restores manually because of this?.?
?
Good luck?/Tom
?
?
We are in the progress of doing a huge restore, which is taking a extremely long time to complete.
I've set the restore to only over write files if the backed up file is newer.
When it needs to write data it has no problem pushing it out, however if the files its trying to restore already exists things appear to drag on, this process seems to be taxing and is slowing down the whole job as it checks each file.
As well the size of the file it is checking effects the length of time it takes for each check from what I see in the logs.
Anyone have any experience in restoring to a location where files already exist?
A couple of examples we have;
a job that contained 5728 files, but was only 43GB in size, majority of the files were already in the location, and this was filling in the gaps, to complete this it took 97 minutes.
Another job that had 11925 files, was 100Gb in size and took 165 minutes to complete.
unfortunately I do not have any decent size restores that had no files in the location it was restoring to. The only job I had was a small one that consisted of 536 files, 2.03GB and took 6 minutes.
Draw back to presstore is that during the restore it only lists the size/number of files it has actually written not what it has skipped therefore not giving me an actual idea of its total progress.
We also learned over the weekend that Queuing up a large list of restore jobs did not play too well, when one job was done with its tape, the unit would eject that tape and then another job would pick up another tape, stopping the first guy from continuing until it had a chance to once more grab a tape. Back and forth this went between different jobs.
The restore queue in presstore is not all that efficient in the way it manages multiple restore jobs.
Am I just better off restoring to an empty location and then rsyncing the 2 directories?
Is there a way to speed this along that I'm not seeing?
presstore is running off a 10.6.5 snow leopard server, we are running presstore 3.2.6.
We are restoring to an Xsan volume that the server has mounted.
Curtis
