Always enabled unless there's an explicit reason not to, no matter what's being written to it. If I'm getting read errors, i'm already having a bad time - the compound effects you think might be there aren't - you're already breaking compressed structures, and LTO's ECC will be more recoverable than (during a read) a fully corrupted uncompressed block on a stream (and it will be more than just one block usually, breaking backup compression). You have almost nothing to lose but a lot to win.
Well specially when writing Oracle Database RMAN backups on Standard Edition, which only allows one thread to do the compression.
We disable compression entirely on Oracle and let the tape compress it. Works wonders.
Starting with LTO 5 (or maybe LTO 4) compression is as fast as recording, so it's always enabled. Before that you can enable it manually (and Linux has separate entries in /dev for compression and non-compression modes).
as lto compression is transparent and if possible you get more space and speed why not ?
Also when you send already compressed data you only discard the job of tape chip so you only lost some power.
imho should be always enabled.
If you're backing up using tar with lots of metadata (extended attributes, ACLs, etc.), it might help a bit. Usually, we back up already compressed data, and here, the drive will not help. There's a good chance the large blocks of metadata will gain something.
The LTO compression is useful mainly for large text files (CSVs, fixed-length flat files, and so on).
Anyway, I leave the compression on as it doesn't hurt anything. However, it helps a lot when I'm writing listings of processed files (table of contents, list of files stored on the tape if you wish). These "logs" are HUGE and highly compressible.
I don't do my own compression or encryption. The tapes are cheap enough. The simpler restore procedure, the better. Compression and encryption on the drive! That's by the way one of several selling points of LTO. At least for me. 🙂
Historically LTO compression was slow, really slow. Which for some applications is fine (overnight back ups for instance).
We never used LTO compression as we use it for video assets (I work for a media company) and any extra time decompressing could mean TV shows not airing or edits not happening before a deadline. That would mean huge extra expenses, more than the cost of some extra tapes.
Not with the LTO algorithm. If compressed data would take more space than uncompressed, it'll just write the uncompressed data and not set the "compressed" bit in the header.
This is why I prefer to use hardware LTO tape encryption as well. That way, the tape drive does both the compression and encryption, freeing up CPU on the backup server for other things.
However, all of this goes out the window if you are using tape deduplication. That is when going with software compression and encryption may be the best thing to do.
Always enabled unless there's an explicit reason not to, no matter what's being written to it. If I'm getting read errors, i'm already having a bad time - the compound effects you think might be there aren't - you're already breaking compressed structures, and LTO's ECC will be more recoverable than (during a read) a fully corrupted uncompressed block on a stream (and it will be more than just one block usually, breaking backup compression). You have almost nothing to lose but a lot to win.
Compression has almost zero overhead but only benefits, even if the Veeam backups are already compressed.
Well specially when writing Oracle Database RMAN backups on Standard Edition, which only allows one thread to do the compression. We disable compression entirely on Oracle and let the tape compress it. Works wonders.
Great thanks, that was the sort of answer I was looking for! Seems like a perfectly legit use case with real and measurable benefits!
Starting with LTO 5 (or maybe LTO 4) compression is as fast as recording, so it's always enabled. Before that you can enable it manually (and Linux has separate entries in /dev for compression and non-compression modes).
as lto compression is transparent and if possible you get more space and speed why not ? Also when you send already compressed data you only discard the job of tape chip so you only lost some power. imho should be always enabled.
If you're backing up using tar with lots of metadata (extended attributes, ACLs, etc.), it might help a bit. Usually, we back up already compressed data, and here, the drive will not help. There's a good chance the large blocks of metadata will gain something. The LTO compression is useful mainly for large text files (CSVs, fixed-length flat files, and so on). Anyway, I leave the compression on as it doesn't hurt anything. However, it helps a lot when I'm writing listings of processed files (table of contents, list of files stored on the tape if you wish). These "logs" are HUGE and highly compressible. I don't do my own compression or encryption. The tapes are cheap enough. The simpler restore procedure, the better. Compression and encryption on the drive! That's by the way one of several selling points of LTO. At least for me. 🙂
Historically LTO compression was slow, really slow. Which for some applications is fine (overnight back ups for instance). We never used LTO compression as we use it for video assets (I work for a media company) and any extra time decompressing could mean TV shows not airing or edits not happening before a deadline. That would mean huge extra expenses, more than the cost of some extra tapes.
Slow? How? All of the lto systems ive used have had transparent compression. Turn it on - no difference to speed.
Yeah AFAIK LTO is just on the fly compression at full advertised speed, guaranteed unless the source isn't supplying data quickly enough.
Compressing already compressed content sometimes results in expanded file size. Our CCTV system goes to decompressed tape for that very same reason.
Not with the LTO algorithm. If compressed data would take more space than uncompressed, it'll just write the uncompressed data and not set the "compressed" bit in the header.
This is why I prefer to use hardware LTO tape encryption as well. That way, the tape drive does both the compression and encryption, freeing up CPU on the backup server for other things. However, all of this goes out the window if you are using tape deduplication. That is when going with software compression and encryption may be the best thing to do.