50
For me, the single biggest argument in favour of tape is that doubling your storage capacity is cheap. That is, to go from 1TB of HDD storage to 2TB is the same as going from nothing to that first TB. With tape, you pay a large premium for the drive, but storage after that is comparitively cheap. You don't have to have lengthy budget meetings about ...
27
Data retention - if you put a disk and a tape with the same data on it in the same physical location it should last a lot longer on tape than on disk - potentially by an order of magnitude.
Also tapes are generally better at dealing with the rigors of being shipped from primary to secondary/off-site data centers multiple times.
18
Consider this situation: You drop a box with 6 months worth of backups down the stairs. If these are tapes in their cases, you pick the box back up and continue on your way. If they are disks, you just lost 6 months worth of backups and you'll probably be job hunting.
It's common practice for couriers to take tapes offsite daily and then return them later. ...
18
In your case it is the file level encryption that is preventing compression.
Encryption tries to make the data stream look as much as random "noise" as possible. Compression tries to increase the data "density" which has a similar effect of limiting further compression.
17
Tapes don't compare with disk quite like that. Tapes are for backing up, and they compare more with deduplicated and replicated disk like Data Domain, or optical media.
The main reason for tape backups is that it's cheap. You can afford to store 10 full copies, even though you don't really need them, because the media is so affordable. The next main reason ...
15
200 GB (marked on the tape) = 200,000,000,000 bytes = ±150 GB (real, 2^30) usable + some metadata.
If you use backup app that has own compression, then there's no hardware compression working with your tape drive, so 200 -> 400 doesn't happen.
IMHO everything works as expected.
13
If your drive is new and the tape is of good quality you can expect to be able to write more bytes to the tape than the official capacity. In some sense you can call that spare capacity, but it isn't unused.
As your drive heads wear down capacity will be decreasing. If you combine that with tapes of not as great quality the capacity can decrease even ...
10
In addition to all the above, there is generally "less stuff to fail" with a tape. It's a very simple device, and you don't have to worry about the onboard electronics (the drive controller with a disk, even SSD). Additionally, their storage and transport requirements are generally a bit looser. They can be subjected to heat and humidity swings as well as ...
8
Veeam can backup to iSCSI and SMB3 natively. I don't see any viable points in using VTL within your particular scenario. Just an opposite: by not implementing VTL layer you just remove one level of complexity! Probably your VAR is trying to make few extra $s up selling you something you don't really need. On your place I'd get something like Dell R730(xd?) ...
7
Typically, if you care about recovering your data after a disaster in an acceptable amount of time, full backups are done regularly (weekly, bi-weekly, whatever) and incrementals or differentials are done daily. Differentials will allow you do do a full recovery in three steps:
Restore the latest full (which will only be a week or two old).
Restore the ...
6
stenc project should be useful (haven't personally tested that) -- http://sourceforge.net/projects/stenc/
5
Backup to tape is great for long term retention, but for recovering from mistakes, we used backup to disk.
Depending on your total storage, this can be a cheap way of keeping at least one copy of every file cheaply and quickly.
Say you have a total of 4TB of storage to backup. It doesn't cost much to build a 12TB backup volume and backup to there. Then ...
5
Each generation of DLT was different:
DLT III is about 365m
DLT IV is about 557m
SDLT I is about 558m
SDLT II is about 630m
5
as everyone has mentioned Tape Drives are used for storage and normally secondary back-ups in large domains.
We would use hard drives as primary backups and tapes as our secondary offsite storage methods. Some companies will also use tape drives for data that is accessed very infrequently.
Tapes currently give about 8.5TB of storage with 353MB/s transfer ...
5
There is no built-in functionality to support backup to tape (and hasn't been starting with Windows Server 2008). You'll need to look at third-party software (of which there are plenty of commercial and some free/open source offerings) for that functionality.
NTBackup writes ".BKF" files, which are file-based representations of the Microsoft Tape Format. I ...
5
As the tape drive has hardware dedicated to compression, your CPU can be used to something else... so yes, it makes sense. On a file server, you want the server to serve the file request, no compressing data for the backup.
Tape drive hardware works "on the fly" ... if you backup some data already compressed as "zip" files, then the compression will likely ...
5
Use common sense. Replace the unit or leverage the manufacturer/warranty contacts.
The behavior you're experiencing is not common or acceptable. Imagine this were a common kitchen appliance like a microwave or your refrigerator. Would you tolerate a weekly failure of those?
Nope...
So apply the same logic to your malfunctioning tape drive :)
5
I don't know anything about Veeam or VRanger/HP Data Protector but I wouldn't expect them to be compatible unless Veeam made specific statements about it.
Even if Veeam made those statements I would certainly have tested the claim before I needed to use it.
The last time I switched backup products I kept my legacy solution available until the retention ...
5
As BaronSamedi1958 said, if you are counting binary gigabytes (GiB) then the capacity of a 200 GB tape is about 186 GiB (200 / 1.0243). This is why I encourage people to use real gigabytes (1,000,000,000 bytes) everywhere except when buying RAM.
However, short tapes occur for a number of reasons.
If the tape or drive is dirty, then some blocks will fail ...
5
Also take in account the blocking factor. If you're using for instance a 128K block size, and you're backing up many small files, as each file occupy at least one block on tape, you end up with a lot of wasted space. Typical disk block size is 4K; on tape for decent performance you'll rarely use less than 32K.
5
Compression assumes it can work. tar files generally can not be compressed (they already are), so yes, you may end up not getting the "average compression ratio". Pure text files may compress a lot more. Compression targets are estimates.
5
The compression is part of the LTO standard, called SDLC, and is a variant of the LZS algorithm
It operates on the data in a block fashion. LTO6 and onward apply this compression to larger data blocks to support higher compression rates.
And, since it's part of the standard, it's the same across the entire LTO ecosystem (minus the change in LTO6+).
4
tapestat, part of the iostat package.
[dan@lnaapp-backup ~]$ tapestat 1 1
Linux 3.10.0-514.el7.x86_64 (lnaapp-backup.internal.lr.org) 05/07/17 _x86_64_ (24 CPU)
Tape: r/s w/s kB_read/s kB_wrtn/s %Rd %Wr %Oa Rs/s Ot/s
st0 0 106 0 27284 0 11 21 0 0
st1 0 0 5 ...
4
In general, tape devices like being written to in blocks, so using dd is probably better than just redirecting output. However, your dd command as written won't do blocking. Depending on your tape device, the block size may be vastly different, but a block size of 4k was(*) typical and would be specified by using bs=4096 in the dd command list. Eg: dd of=/...
4
Your version of tar appears to be trying to write to the tape device by default, rather than standard output. It appears to be GNU tar. Autodetecting the tape drive was the default before version 1.11.5 of GNU tar and I suspect you have such an old version. Versions of tar on other UNIX systems may also attempt to write to the tape device by default.
Force ...
4
Usually with tape devices you don't have to do anything special to overwrite them - simply start writing again from the beginning of the tape, and whatever was already on there is gone.
As a FAQ for one classic backup program notes, the problem is usually the reverse: most tape devices are so keen to rewind to BOT and start overwriting their payload, that ...
4
First you have to make contact with your tape drive. Ultrium448 is a scsi one, but it has a linux driver, thus it can't be an issue. Probably you have to reach the tape disk on a char device. HP provides linux drivers for the task, if you have trouble, I suggest to ask detailed in a new question.
The backups are coming with a .bkf extension. If this is the ...
answered Apr 20 '15 at 17:22
peterh - Reinstate Monica
4,73610 gold badges26 silver badges44 bronze badges
4
I know this is an old question, but it is the first question that shows up when searching "commvault" on serverfault.
I have two years of experience with Commvault Simpana v9 and v10 as a support technician and a year as a systems engineer.
First Question
To answer your first question, yes, a typical database restore creates
.mdf and .ldf files which ...
4
Check Veeam Backup and Replication. In v9.5 they allow to append incomplete tapes.
https://helpcenter.veeam.com/archive/backup/95/vsphere/add_gfs_media_pool_advanced.html
The community edition is free for a use of 10 or fewer VMs.
Haven't yet upgraded to their new v10.
3
I have tested stenc as suggested by sendmoreinfo and it worked well with the LTO-6 drive.
Usage:
Insert a tape and ask the tape drive about its settings:
# stenc -f /dev/nst0 --detail
Generate your 256 bit key and store it:
# stenc -g 256 -k /root/myaes.key -kd Bobs_month_key
Load the key in the LTO tape drive. With --ckod it will forget the key after ...
Only top voted, non community-wiki answers of a minimum length are eligible
