On Thu, Apr 28, 2016 at 12:02 PM, Paul Groves
Not sure what you are doing, but hardware compression is transparent to tar. It has no idea how much data is on the tape or how much physical space it taking up.
Suspected as much. Thanks Greg.
Does anyone know how can I check the real size of the data on the tape?
Also, I have tried running a backup until the end of tape message:
I am using an LTO3 tape which is 400GB native (up to 800GB) so I would expect somewhere between these values. The directory contains many un-compressed media files so should be compressible, and it is only 368GB in size. It stops at around about 250-300GB mark by my estimation, which was my original problem. It isn;t even using anywhere near it's native size.
I regularly fit 300 - 370GB on an LTO2 tape at work with Symantec backup exec! I shouldn't need an LTO3 here (depending on the compression rate then I might go a few GB over).
I have to say, this is not a well documented process. Hopefully someone has used this successfully before?
What is the block size your backup software using to write data to the tape? The block size will effect not only the rate at which data can/will be written to tape but also the amount of data which can be written to a single tape. In a past life I used Amanda to backup systems to LTO2 and LTO3 libraries and with the default 32k block size saw horrible performance, nowhere near what the devices could provide. After much trial and error determined that setting a block size of 128M or 256m, it escapes me, was needed for the drives to perform at their maximum rate. This certainly limited the amount of data I would write to tape, but didn't care too much since these were attached to like 12 tape libraries.
P.S. Same issue with LTO4, LTO5 and LTO6 drives at work so this is obviously a common problem. All the drives are HP Ultrium Storageworks.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org