PKZIP for VMS vs backup/log

[Kenneth Toler]

What are the advantages of PKZIP vs backup/log? The savesets are now in excess of 500,000 files with more than 1,000,000 close at hand. Is PKZIP more efficient as far as zipping and unzipping?

[Joseph Huber_1]

Your backup does compress ?

I always wished that, compressing ("zipping") is the only reason I use (Info-)ZIP on VMS instead of backup.

[Steven Schweda]

As I always ask:

Real PKZIP as in http://www.pkware.com/ , or
Info-ZIP as in http://www.info-zip.org/ ?

Note:

http://www.pkware.com/documents/announcements/EOL_OpenVMS.pdf

Better hurry, if you want support.

The "advantages" of anything depend on what
you're doing and why.

BACKUP to what? Modern tape drives tend to
offer built-in compression. BACKUP why?
Archiving? Distribution?

Similarly, "efficient" in what sense? Time?
Space? (In which universe?) Any
compression scheme tends to trade time for
space. Of which do you have more available?

I don't immediately see the relevance of the
_number_ of files, as opposed to, say, the
total size of the files.

[Joseph Huber_1]

The backup "compress" Steven mentioned, of course is not compression done by backup, backup just tells (tape-)devices capable to do so.

A comparison between backup and (whatever) zip makes only sense for backup/archive files on disk:
A zip archive can be listed without uncompressing, and You can extract files without uncompressing the whole archive.

With backup, you can compress the complete save-set (gzip or bzip2). but listing/extracting is only possible after decompressing the whole saveset.

[Ian Miller.]

backup also includes information to help with recovery of the files
backup is supported by the fine people who wrote the operating system - who do you trust when there is a problem recovering your data?

and in VMS 8.3
BACKUP/DATA_FORMAT=COMPRESSED
Instructs BACKUP to create a compressed save-set (using ZLIB)

[Bob Blunt]

Kenneth, what are your goals? If you're "just" trying to save the data in case something might go wrong and it's not that important to your business or you if the data's always available, then just about ANY solution is fine.

However, IF your business needs that data AND you might ever have a need to recover from a catastrophy, you also need to consider the possibility that you may be starting from scratch. Booting either the O/S distribution CD/DVD, a minimum O/S build on an alternate disk or good old Standalone BACKUP (if we're talking VAX, of course). Consider that you might not have a current release of that software available on the O/S release kit to unbundle your 'savesets.'

Consider what options you have and the amount of time you have in which to complete them. While slow, tape may be your best bet. If storage is not a precious commodity, then saving your data in savesets to an alternate disk(s) might be best. You can always ZIP/compress the savesets once you've got a safety net built to cover your most extreme situations.

As far as a direct comparison between tools? I've used common ones to move data between dissimilar operating systems, ZIP to create a set of data on a MicroVAX and then a GUI style UNZIP rendition on a destination WinTel server to recreate the data with exact folder tree structure as was on the VAX. It worked and the customer was able to get their data working just fine. The familiar directory tree helped them find things.

So, in a nutshell, there aren't overwhelming differences in the available tools but you do need to establish your needs, goals and expectations before making a choice. The BACKUP utility isn't perfect, it isn't infallable, but none of the other solutions are any more perfect or secure. BACKUP has distinct advantages in an OpenVMS environment and can be used in conjunction with other optional tools to help make a palatable solution if BACKUP's ways aren't exactly what you need.

[Kenneth Toler]

I am trying to backup up to 200 GB using 4mm tapes. My customer wants to know is there a way that is quicker/ more efficient than using the backup command to try to re-expand the savsets we porvide them.

[Ian Miller.]

so the key thing you are trying to do is to speed up the restore from backup save sets on DAT tapes?

[Steven Schweda]

> I am trying to backup up to 200 GB using
> 4mm tapes.

I'll try again. BACKUP why? Archiving?
Distribution?

How many 4mm tapes does it take to hold 200GB
these days? (You could read this as, "What
kind of tape drives are you using?", and,
"Do your tape drives do compression?".) Why
4mm tapes?

If your tape drives can do compression, then
it's not obvious to me what more you can
gain by using (any form of) Zip compression.

If speed is of interest, why not use a
portable 200GB SCSI disk?

From time to time, a clear, detailed
explanation of the actual problem which you
are trying to solve can be more useful than a
request for information about how to
implement a sub-ideal solution to that
problem.

[Jon Pinkley]

Kenneth,

This brings back memories of backing up a 20MB PC drive to 360K floppies :-)

How many tapes does it currently take to backup 200 GB? Do your DAT drives have compression capabity, and if so, are you enabling it? $ backup/rewind/media=comp ...

I am not even sure that zip is going to be an option, unless the data is extremely compressible, or you can create multiple .zip files. At least there used to be 2 or 4 GB limit (32bit signed/unsigned) on the size of the zip file. Perhaps this was related to you original question about PKZIP, they may have a version that doesn't have the 32bit size field, but these wouldn't be backward compatible with the old .zip files.

How often are you providing them the whole 200 GB of data? Is all the data changing, i.e. is each new deliverable completely new data, or can an incremental backup be used to just provide a "delta" of what has changed? What versions of VMS are you and they using? If you are both using 8.3 then backup's compression could reduce the amount of data going to the tapes, assuming your DAT drives don't have built in compression hardware.

How much is your/their time worth? A new/bigger/faster tape drive that has compression built in would save the most time. Or as Steven Schweda said (just read his response) a large SCSI drive in an external case that can be transported.

Summary, unless the data you are copying is highly compressible, it is still going to take many DAT cartridges to backup 200 GB of data.

Good luck,

Jon