How do the old compression level names correspond to the new level names ?

[Mrx]

How do the old compression level names correspond to the new level names ?

eg. what is Enhanced speed A on new 4.06 vesion ?

[OldNavyGuy]

While your waiting, see page 66 of the 4.06 IFW User Manual for an explantion of the new compression options.

If you can find a copy of the prior version manual, do a diff.

[TeraByte Support(PP)]

TB - Fastest = Enhanced Speed - A

Code: Select all

New                Old
---------------------------------------------------
None               None
TB – Standard      Standard
ZLIB – Good        Enhanced Size - A
ZLIB – Better      Enhanced Size - B
ZLIB – Best        Enhanced Size - C
IPP – Good         Enhanced Size - D
IPP – Better       Enhanced Size - E
IPP – Best         Enhanced Size - F
TB – Fastest       Enhanced Speed - A
TB – Faster        Enhanced Speed - B

[Gavin]

I was going to mention the old compression options in my next post as the IFW, for example, manuals description wasn’t of much help in explaining the differences with real measurable data. And I read them and read them and was still left scratching my head. LOL! The manuals description went on to compare descriptively the impact of compression types on image creation time/speed.

The new compression-speed/image creation time options is better but personally, there are to many. The manuals explanation on the new compression/speed options is an improvement but I think we can do better on this. I’m on page 90 of the IFW manual and the compression-speed explanations require me to read them time and time again because they are not memory sticky.

To make sense of the compression/speed options now, I’m left with having to carry out real-world testing, which is time consuming but fun as a hobbyist. For the commercial environment, they will have to weigh the compression used with its impact on image creation time and CPU etc resources. I can use any other 19 options without any issues but for the commercial environment this won’t be so. Because, if the system is hitting it hard on the best compression, it’s resources will be hit harder. May be to hard.

What’s odd is that the manual states that certain compression algorithms have a greater impact on image creation time than others and therefore image size. Yet when I have carried out my own testing, to make head-and-tails of the compression/speed options available, this didn’t seem to follow. I was in the process of repeating the whole compression-speed testing throughout today again just to be certain the data I have makes sense before posting.

UK SAS special forces have a saying, ‘Keep it simple and stupid’. The compression options are far from this.

So I would go:

1) NON - No compression/high speed
1) MIDDLE – compression/medium speed (best-of-both-worlds)
2) HIGH – compression/low speed (increase in time)

You can see

1) LOW = HIGH
2) MEDIUM = MEDIUM
3) HIGH = LOW

Let’s start here and work out.

With HDDs and NVME’s in the TB, space shouldn’t be an issue for the general user. I don’t know about commercial or server environment.

I’m not saying 3 choices is the right way to go but as it stands, we have 19. Yikes!!!

Using other established backup/restore programs, I’ve always gone ‘no compression’ or ‘standard compression’ – best-of-both-worlds. But I’m just a hobbyist and TBU software is used seriously in the commercial domain too. They may need 19 choices.

By doing real-world testing, I will be able to make an informed choice. If we are going with 19 choices, let’s see the data for each.

So, for example, for the manual,...

1) No compression = no speed/time impact = 90GB
2)...


19)

I will get back to testing later today.