Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Request for feedback - BACKUP enhancement

SOLVED
Go to solution
Antoniov.
Honored Contributor

Request for feedback - BACKUP enhancement

13 REPLIES
Uwe Zessin
Honored Contributor

Re: Request for feedback - BACKUP enhancement

I really hope that backup will not loose its robustment like after the first rewrite. My suggestion is that the new functionality is first offered as a separately installable kit (similar to the new LAT stuff in V5.4-3) with the ability to back-out.
.
Jan van den Ende
Honored Contributor

Re: Request for feedback - BACKUP enhancement

Guy,

I like the idea of two (more?) simultaneous tapes written.

I have always wondered why the disk-to-memory pass and the memory-to-tape pass had to alternate.
Using half the memory to fill from disk while transfering the other half to tape simultaneous look like a very simple way for significant speedup.
And the idea is hardly new: in the early 80's I wrote somthing along those lines as a print despooler (for Qume printers having 2 128-byte buffers).

Like some of the others on COV I am not yet convinced that striping will be advantageous for restorability.

I do not know if this is even possible, but would it (PLEASE!!) be possible to re-introduce BACKUP's ability for recovering tape errors (also on SCSI tapes).
I could live with write errors remaining uncorrectable, but loosing a full tape of backup because of ONE parity error still looks REAL stupid!

Guy, GO FOR IT.
If anyone can do it, you are that one.

Proost.

Have one on me.

jpe

Don't rust yours pelled jacker to fine doll missed aches.
David Jones_21
Trusted Contributor

Re: Request for feedback - BACKUP enhancement

>>Like some of the others on COV I am not yet convinced that striping will be advantageous for restorability.<<

It's disadvantageous from the increased risk of tape failure, but advantageous from the perspective that full image restore would happen up to n times faster (for a stripe set with n tape drives).

Geez people, the proposal was for the tape equivalent of RAID 0 and RAID 1 and everyone's demanding it be RAID 5.

The last time I worked on a system with dual tape drives, Reagan was president.
I'm looking for marbles all day long.
Galen Tackett
Valued Contributor

Re: Request for feedback - BACKUP enhancement

Jan,


I do not know if this is even possible, but would it (PLEASE!!) be possible to re-introduce BACKUP's ability for recovering tape errors (also on SCSI tapes).
I could live with write errors remaining uncorrectable, but loosing a full tape of backup because of ONE parity error still looks REAL stupid!


I think this has been discussed before at some length probably both here and on c.o.v. Though I don't know the details I believe this inability to recover from tape errors isn't backup's fault, but is due to the way that newer tape subsystems work.

Others here can probably better summarize why this is true.

Maybe VMS's tape parity error message is too generic? If memory servers this kind of error might bue due to much more serious problems than just a bad bit or two, perhaps even so serious that the tape is literally unreadable beyond that point.
Ian Miller.
Honored Contributor

Re: Request for feedback - BACKUP enhancement

The issue with modern tapes is due to what the tape firmware does in reaction to an error.

BACKUP could be improved to give better error reports if it gets enough enough information back from the tape drive.
____________________
Purely Personal Opinion
Jan van den Ende
Honored Contributor

Re: Request for feedback - BACKUP enhancement

Ian,

I _know_ it is a SCSI firmware issue.
I am just praying that there is some way to force it to resume, _AND_, in that case, I dearly wish Engeneering to implement that ïn a way that makes BACKUP resume its old behavior.

There must be _SOME_ way around the parity error, as demonstrated by the info rescue companies.
But I have not the faintest idea whether some of their methods can be integrated into BACKUP :-(
Just hoping, and keep pushing.

After all, Ã got much the same answer when asking for SCSI minimerge. And I asked again and again at every Decus Engeneering panel, year after tear. It took over 10 years, but: LOH & BEHOLD !

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

Re: Request for feedback - BACKUP enhancement

Bigger blocksizes on tape would be nice to get better performance. May be time to modify RMS ...

And /stat to get statistics of thruput and save set size.

And writing directly to remote tapes using TCP and DECNET.

And /group should default at 0.

And dismount/wait=rewind should wait until the tape is rewinded.

Wim
Wim
Ian Miller.
Honored Contributor

Re: Request for feedback - BACKUP enhancement

Wim - I would not be surprised if some of your wishes appear in a future version of vms

jpe - DEC used to do their own firmware for other peoples tapes. I don't know if hp do but if they did then they could fix this.
____________________
Purely Personal Opinion
Cass Witkowski
Trusted Contributor

Re: Request for feedback - BACKUP enhancement

I remember many years ago some took 5 TKxx or DLT tape drives and with hardware created a RAIT-3 tape backup. The system thought it was one tape drive but it wrote data out to 5 tapes. One being parity so if you lost a tape you would not lose all your data. I think the throughput was 12 MB/second which was pretty good at the time.

I'm currently testing out Ultrium LTO 2 tape drives as replacements to TZ89s. The problem I have is how much CPU time backups take.

On a DS10 (4/466) system I can back up to a TZ89 at 8.37 MB/s using 38% of the CPU. This is with the default of /CRC and /GROUP=10.

Using the new Ultrium LTO 2 tape drive I can backup at 21 MB/s but I'm using 100% of the CPU

If I set /GROUP=0 I still use 100% of the CPU but I can backup at 25.63 MB/s

If I set /NOCRC my CPU utilization drops to 33% but I only backup at 23.14 MB/s due to those group XOR blocks

If I set /NOCRC and /GROUP=0 the CPU utilization drops to 15% and my backup rate is 25.63 MB/s

The point I'm trying to make is that to really get the throughput without killing the system then we need to re look at the effectiveness of the /CRC qualifier. With the current generation of SCSI and Fibre Channel interfaces and the error detection on tape drives what is the value of using /CRC?

What is the probability of a undetected error getting through the system? This is the only thing that /CRC is good for. It's not the error rate of the tape drive it is the undetected error rate of the tape drive and the interface (SCSI or FC) from the host to the tape drive. Is CRC buying us anything.

It has a big impact on how fast I can backup my data and not kill my CPU.

I like the ability to shadow tapes but also mention earlier to be able to make a copy of a tape especially if the block size is larger than 32,256.

I think if you are going to stripe tapes you may want to look at also providing a RAIT-3 capability which give us some sense of recovery if we lose a tape. This would be a nice feature for those who have to archive data.

If you can add statistics or performance metrics in backup such that we can track where backup is waiting. This will help simplify tuning of backups.

Thanks

Cass
Uwe Zessin
Honored Contributor

Re: Request for feedback - BACKUP enhancement

> With the current generation of SCSI and Fibre Channel interfaces and the error detection on tape drives what is the value of using /CRC?

It is still a full end-to-end check. Once upon a time I had a situation where BACKUP had created a corrupted save-set when writing to a remote DECnet node (node::saveset.BCK/SAVE_SET). It was detected during /VERIFY/CRC.
.
Allan Bowman
Respected Contributor

Re: Request for feedback - BACKUP enhancement

I love the idea of creating two tapes at the same time! For a number of years I had to do my development system backups to disk so that I could make two identical tapes - one for off-site storage and the other for emergency restores (and they had to be truly identical). If we had the two tape capability, I would not have hesitated to get a second tape drive for the system rather than adding more disk drives.

Allan in Atlanta
Uwe Zessin
Honored Contributor

Re: Request for feedback - BACKUP enhancement

I think HP Data Protector can do it now, but there is a 'little bit' more involved than just entering:
$ backup ...
.
Guy Peleg
Respected Contributor
Solution

Re: Request for feedback - BACKUP enhancement

I would like to thank everyone for their feedback.

While I did not response to every one of the replies
(or the 100 extra messages sent directly to me) I sure
read it all.....

We have some research to do, although it looks like there
is an interest in these features (while implementation is
yet TBD) and I'll keep you guys posted.

Here is a quick update on latests happenings with
BACKUP:

1. Starting with V8.3 BACKUP will support encrypting
savesets using AES encryption.

2. Latest BACKUP ECO shipped couple of weeks
ago, updated the BACKUP$_OPERSPEC message
to include requesting PID and target device, this helps
identify the process making the request when parallel operations
are being performed.

3. BACKUP has been enhanced to support Dynamic Volume
Expansion - preserve the logical size and expansion size of the
disk. Also we added two new qualifiers /LIMIT & /SIZE
to allow specifying the expansion size and logical size regardless
of the values stored in the saveset. This functionality will ship with
V8,3 and with the next round of BACKUP ECOs (if you need
it earlier contact your support center).

Currently we are in the process of improving the way BACKUP
is handling I/Os to reduce the disk queue load.

Again thank you for your feedback.

Guy Peleg
OpenVMS Engineering