It actually does Andreas, will post further when I got it in the
Datacenter and start testing.
Thanks a lot for your input!
On Tue, Aug 21, 2012 at 5:21 PM, wrote:
>
> Zitat von Horacio Lo Brutto :
>
>> Have any of you tried Bacula with the IBM TS3100 Tape Drive? We will
>> have to configure on
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 Horacio Lo Brutto :
> Have any of you tried Bacula with the IBM TS3100 Tape Drive? We will
> have to configure one of those in one of our customers and we are in
> doubt.
Looks like a branded device from BDT-Solutions
(http://www.bdt-solutions.eu/) which are also sold by HP as far as
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
Have any of you tried Bacula with the IBM TS3100 Tape Drive? We will
have to configure one of those in one of our customers and we are in
doubt.
We couldn't take the equipment to the Datacenter yet, so we cant tell
how is it recognized by the OS. But it will be installed in a Linux
Box with Debian
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
I've been using bacula with S3 using s3fs for about 6 months. To say
it has been flakey is an understatement and I plan to make changes
over the coming months, although still using s3/glacier. s3fs is a
filesystem for S3, I believe the only free one (it's GPLv2).
Backups:
Small backups are fine, b
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
Good Afternoon All,
On 21 Aug 2012, at 13:38, eric santelices wrote:
> With Amazon announcement of Glacier it seems like a natural fit for Bacula.
> Does anyone know if/when we would see support for this storage resource?
If you wanted to utilize this, wouldn't it be better to have the OS loo
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
On 8/21/2012 8:38 AM, eric santelices wrote:
> With Amazon announcement of Glacier it seems like a natural fit for
> Bacula. Does anyone know if/when we would see support for this
> storage resource?
It is not a good fit for direct access media. Uploading could be
accomplished, since large fi
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 2012-08-21 08:38, eric santelices wrote:
> With Amazon announcement of Glacier it seems like a natural fit for
> Bacula. Does anyone know if/when we would see support for this
> storage resource?
Speaking as the person who wanted PostgreSQL support, Glacier support
will arrive when someone who
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.
With Amazon announcement of Glacier it seems like a natural fit for Bacula.
Does anyone know if/when we would see support for this storage resource?
--
Live Security Virtual Conference
Exclusive live event will cover all t
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
29 matches
Mail list logo
