3 ms·

one thing to emphasize is that the quoted LTO capacity numbers are usually including transparent device compression - if your data is not compressible, such as

by paulmd 5y ago

one thing to emphasize is that the quoted LTO capacity numbers are usually including transparent device compression - if your data is not compressible, such as ZIP/RAR files or compressed audio/video, that's not the number you will get! Home users will really want to think in terms of the "raw capacity" imo. This is normally half of the advertised capacity for the older standards (I believe the newer ones have stronger compression that squeezes a bit more). LTO-5 tapes are 1.5tb raw, for example. Maybe you'll get a little bit out of it, but a lot of the things you'd want to back up (and especially the bulkier stuff that really eats space) are already compressed. Family photo library, audio/video storage? JPGs are compressed, H264/H265 or MP3/FLAC/etc are already compressed. System images? A lot of application files are already compressed. Home user scenarios are not outlook mailboxes and database backups like the "official" scenarios.

nybble41 5y ago
> Home users will really want to think in terms of the "raw capacity" imo. Everyone would be better off thinking in terms of the raw capacity. "Compressed capacity" is nothing but a marketing gimmick. Even in enterprise use cases the compression ratios will vary, and the drive's transparent compression is unlikely to offer the most savings. If your data is at all compressible you should compress the backup yourself before sending it to the drive.
- dark-star 5y ago
  It actually works pretty well. Compression in the tape drives is certainly worse than what you could achieve by zipping before, but at least it works at line speed (which is a couple hundred megabytes per second). Factor in the fact that you often write out multiple streams in parallel from a single server to multiple tapes, and it'll become rather tricky to find a compression algorithm that keeps up AND compresses better than the drive. And most enterprises don't really care if their monthly backup requires 10 or 15 tapes. And zipping it all up beforehand requires even more space on the primary storage which is even more expensive than a couple dozen tapes
  - nybble41 5y ago
    It's still misleading to market the tapes based on a compression factor which will depend in practice on the data being stored. The tape's capacity is one thing; the effectiveness of the drive's hardware-accelerated compression algorithm on any given dataset is something else entirely. The two should not be mixed.

by paulmd 5y ago

nybble41 5y ago

> Home users will really want to think in terms of the "raw capacity" imo. Everyone would be better off thinking in terms of the raw capacity. "Compressed capacity" is nothing but a marketing gimmick. Even in enterprise use cases the compression ratios will vary, and the drive's transparent compression is unlikely to offer the most savings. If your data is at all compressible you should compress the backup yourself before sending it to the drive.

dark-star 5y ago
It actually works pretty well. Compression in the tape drives is certainly worse than what you could achieve by zipping before, but at least it works at line speed (which is a couple hundred megabytes per second). Factor in the fact that you often write out multiple streams in parallel from a single server to multiple tapes, and it'll become rather tricky to find a compression algorithm that keeps up AND compresses better than the drive. And most enterprises don't really care if their monthly backup requires 10 or 15 tapes. And zipping it all up beforehand requires even more space on the primary storage which is even more expensive than a couple dozen tapes
- nybble41 5y ago
  It's still misleading to market the tapes based on a compression factor which will depend in practice on the data being stored. The tape's capacity is one thing; the effectiveness of the drive's hardware-accelerated compression algorithm on any given dataset is something else entirely. The two should not be mixed.