>Hi John... Is it possible that the backup job you are trying to restore from >was running at the same time as other backup jobs were running (eg: concurrent >jobs enabled)? > >If yes, then what might be going on here is that several jobs from several >clients were written to the tape at the same time, and the data from each job >was "interleaved", so the write to tape during the backup was fast, but now >the trade-off is that restores will be slow since the tape drive needs to read >parts of the files it wants to restore, skip the files from other >servers/jobs, lather, rinse, repeat. > >It could also explain the initial fast restore of some data as it is possible >that this particular backup job you are trying to restore was "already in >progress" when the other started so it had full access to the storage and it >was the only one writing to the tape. > >Something to consider.
Well, this was an archive job and I ran it during the day when no other backups were running. Also, I have Bacula configured to only write a single job to each tape for the archive pool (Maximum Volume Jobs = 1). John -----Original Message----- From: Bill Arlofski [mailto:waa-bac...@revpol.com] Sent: Thursday, July 15, 2010 7:06 PM To: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Bacula 5.0.2 restore files from tape very slow On 07/15/10 14:07, May, John wrote: > I am using Bacula 5.0.2 using MySQL on Centos 5.4 x64. I'm trying to > restore some files from a backup I made a couple months ago. I the restore > is about 1.5 TB in size and spans two LTO4 tapes. I can start the restore > just fine and the first 5GB flies by in a minute or so, then the restore sort > of stalls and starts crawling. It slows down to about 1MB/s down from about > 70MB/s. There are only about 15,000 files on the tapes and I am restoring to > a local Raid 0 array. > > I tried to bextract the files with and without a bootstrap file and the speed > is still very slow. I also verified I have the correct the indexes in Mysql > and I compacted the database. > > At this rate, I don't think the restore will finish, because it is going so > slow. > > Any ideas on what's going on? > > -- John Hi John... Is it possible that the backup job you are trying to restore from was running at the same time as other backup jobs were running (eg: concurrent jobs enabled)? If yes, then what might be going on here is that several jobs from several clients were written to the tape at the same time, and the data from each job was "interleaved", so the write to tape during the backup was fast, but now the trade-off is that restores will be slow since the tape drive needs to read parts of the files it wants to restore, skip the files from other servers/jobs, lather, rinse, repeat. It could also explain the initial fast restore of some data as it is possible that this particular backup job you are trying to restore was "already in progress" when the other started so it had full access to the storage and it was the only one writing to the tape. Something to consider. -- Bill Arlofski Reverse Polarity, LLC ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
