Nils Juergens writes:
> for me (with LTO-3) increasing Maximum block size has had quite the
> impact on performance.
>
> Sadly, with the new setting I had trouble reading my tapes so switched
> back to the old configuration.
in Linux, you can configure your tape drive to accept variable block
si
On Aug 21, 2012, at 12:53 PM, lst_ho...@kwsoft.de wrote:
> BTW: Do you need some Hardware? We have a Overland LXB Powerloader
> (DLT-8000) near the dustbin ;-)
I am going to guess it is in Germany and I know I'm in USA. :)
--
Dan Langille - http://langille.org
-
Zitat von Phil Stracchino :
> On 08/21/12 13:10, Alan Brown wrote:
>> On 21/08/12 17:50, Dan Langille wrote:
>>> All my backups are in my basement. Including the tapes. I really
>>> should move the latest full backups somewhere else.
>>
>> Preferably "sooner" rather than "later".
>>
>> One of our
Zitat von Alan Brown :
> On 21/08/12 15:40, Sven Tegethoff wrote:
>
>> At my previous company, we used to do a primary backup on a local backup
>> server, and then copied it over a 100mbit WAN line to a secondary
>> offsite server at a colocation center over the course of the day.
>
> If I was to
Zitat von Alan Brown :
> On 21/08/12 17:46, lst_ho...@kwsoft.de wrote:
>
>>> That means there's some room for improvement in despooling speed,
>>> but the big bottleneck at the moment is disk-fd and fd->sd, not
>>> sd->tape - the best achieved there is a sustained 52MB/s and that
>>> virtually ma
On 08/21/12 13:10, Alan Brown wrote:
> On 21/08/12 17:50, Dan Langille wrote:
>> All my backups are in my basement. Including the tapes. I really
>> should move the latest full backups somewhere else.
>
> Preferably "sooner" rather than "later".
>
> One of our staff was burgled recently. The thie
On 21/08/12 15:40, Sven Tegethoff wrote:
> At my previous company, we used to do a primary backup on a local backup
> server, and then copied it over a 100mbit WAN line to a secondary
> offsite server at a colocation center over the course of the day.
If I was to do this, the 100Mb/s WAN would be
On 21/08/12 17:50, Dan Langille wrote:
>> Assuming your DLTs are DLT8000, 12 hours is about spot-on for the raw
>> capacity and speed of the tape (40GB raw + 7GB/hour)
>
> In my case, DLT7000.
DLT7k is only slightly slower
>> WRT "offsite backups" - I'm more inclined to use a good firesafe in a
On 21/08/12 17:46, lst_ho...@kwsoft.de wrote:
>> That means there's some room for improvement in despooling speed,
>> but the big bottleneck at the moment is disk-fd and fd->sd, not
>> sd->tape - the best achieved there is a sustained 52MB/s and that
>> virtually maxes out a 1Gb/s NIC. Even if the
Zitat von Dan Langille :
> On 2012-08-21 05:42, Alan Brown wrote:
>> On 21/08/12 08:37, lst_ho...@kwsoft.de wrote:
>>> Some short tests with the "Maximum Block Size" set, show transfer
>>> speed to the LTO-4 of 87MBytes/sec with 256K and 98MBytes/sec with 1M
>>> with Bacula encrypted data, so wit
On Aug 21, 2012, at 12:38 PM, Alan Brown wrote:
> On 21/08/12 16:04, Dan Langille wrote:
>
>> ###
>> The DLT drive default data block transfer size is 4KB (4096 bytes).
>> To achieve better performance, adjust block size to 32K bytes or
>> higher when using a fixed block device.
>> ###
>
> What
Zitat von Alan Brown :
> On 21/08/12 16:04, Dan Langille wrote:
>
>> ###
>> The DLT drive default data block transfer size is 4KB (4096 bytes).
>> To achieve better performance, adjust block size to 32K bytes or
>> higher when using a fixed block device.
>> ###
>
> What you want to know is how bi
On 21/08/12 16:04, Dan Langille wrote:
> ###
> The DLT drive default data block transfer size is 4KB (4096 bytes).
> To achieve better performance, adjust block size to 32K bytes or
> higher when using a fixed block device.
> ###
What you want to know is how big it can go - and the only way to kn
On 2012-08-21 05:42, Alan Brown wrote:
> On 21/08/12 08:37, lst_ho...@kwsoft.de wrote:
>> Some short tests with the "Maximum Block Size" set, show transfer
>> speed to the LTO-4 of 87MBytes/sec with 256K and 98MBytes/sec with
>> 1M
>> with Bacula encrypted data, so with this we are reaching the
>>
Zitat von Sven Tegethoff :
> On 21.08.2012 16:07, lst_ho...@kwsoft.de wrote:
>>> Not very many. The vast majority of bacula installations use disk
>>> volumes, not tape - which is why debugging tape problems can take so
>>> long.
>> I always wonder how they handle offsite backup for disaster reco
On 21.08.2012 16:07, lst_ho...@kwsoft.de wrote:
>> Not very many. The vast majority of bacula installations use disk
>> volumes, not tape - which is why debugging tape problems can take so
>> long.
> I always wonder how they handle offsite backup for disaster recovery...
> Maybe the plan is simply
Zitat von Alan Brown :
> On 21/08/12 13:00, lst_ho...@kwsoft.de wrote:
>
>> Of course but the manual as far as i understand explicitely discourage
>> altering the value for Block Size with modern hardware: "On most
>> modern tape drives, you will not need to specify this directive.."
>
> That's o
On 21/08/12 13:00, lst_ho...@kwsoft.de wrote:
> Of course but the manual as far as i understand explicitely discourage
> altering the value for Block Size with modern hardware: "On most
> modern tape drives, you will not need to specify this directive.."
That's on the basis that 64k is universal.
Zitat von Alan Brown :
> On 21/08/12 12:27, lst_ho...@kwsoft.de wrote:
>
>> So i still wonder why the manual recommend not to change this value?
>
> Because some (older) drive types don't like it and will break.
Of course but the manual as far as i understand explicitely discourage
altering th
On 21/08/12 12:27, lst_ho...@kwsoft.de wrote:
> So i still wonder why the manual recommend not to change this value?
Because some (older) drive types don't like it and will break.
> The problem of not mixing the blocksize is obvious so if there is not
> other downside one should choose a larger
Zitat von Alan Brown :
> On 21/08/12 08:37, lst_ho...@kwsoft.de wrote:
>> Some short tests with the "Maximum Block Size" set, show transfer
>> speed to the LTO-4 of 87MBytes/sec with 256K and 98MBytes/sec with
>> 1M with Bacula encrypted data, so with this we are reaching the
>> theoretical
On 21/08/12 08:37, lst_ho...@kwsoft.de wrote:
> Some short tests with the "Maximum Block Size" set, show transfer
> speed to the LTO-4 of 87MBytes/sec with 256K and 98MBytes/sec with 1M
> with Bacula encrypted data, so with this we are reaching the
> theoretical uncompressed speed of the LTO-4 d
Zitat von lst_ho...@kwsoft.de:
> Zitat von Nils Juergens :
>
>> Hello Andreas,
>>
>> Am 20.08.2012 17:29, schrieb lst_ho...@kwsoft.de:> As the tape is
>> altering speed all the time with Bacula i would like to
>>> know if there is a possibility to get closer to the dd values and what
>>> could be
Zitat von Alan Brown :
> On 20/08/12 16:29, lst_ho...@kwsoft.de wrote:
>> Hello List
>>
>> this has been discussed already some times on the list but as i have
>> ssen no real conclusion i will ask for opinion again. The setup is
>> Bacula 5.2.10 on Ubuntu 12.04 LTS (x64) with a LTO-4 drive conne
Zitat von Nils Juergens :
> Hello Andreas,
>
> Am 20.08.2012 17:29, schrieb lst_ho...@kwsoft.de:> As the tape is
> altering speed all the time with Bacula i would like to
>> know if there is a possibility to get closer to the dd values and what
>> could be the bottleneck in such a setup?
>
> for
On 20/08/12 16:29, lst_ho...@kwsoft.de wrote:
> Hello List
>
> this has been discussed already some times on the list but as i have
> ssen no real conclusion i will ask for opinion again. The setup is
> Bacula 5.2.10 on Ubuntu 12.04 LTS (x64) with a LTO-4 drive connected
> through Adaptec 29320LPE,
Hello Andreas,
Am 20.08.2012 17:29, schrieb lst_ho...@kwsoft.de:> As the tape is
altering speed all the time with Bacula i would like to
> know if there is a possibility to get closer to the dd values and what
> could be the bottleneck in such a setup?
for me (with LTO-3) increasing Maximum block
Hello List
this has been discussed already some times on the list but as i have
ssen no real conclusion i will ask for opinion again. The setup is
Bacula 5.2.10 on Ubuntu 12.04 LTS (x64) with a LTO-4 drive connected
through Adaptec 29320LPE, a 320MByte/sec PCI-Express controller. To
preven
28 matches
Mail list logo
