|
|
Antoniov.
|
|
|
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
|
|
|
Sort Answers By:
Date or Points
|
|
Uwe Zessin
|
|
Nov 7, 2005 13:32:03 GMT
5 pts
|
|
|
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
|
|
Nov 7, 2005 14:16:55 GMT
5 pts
|
|
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 |
|
David Jones
|
|
Nov 7, 2005 21:27:19 GMT
5 pts
|
|
>>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. |
|
Galen Tackett
|
|
Nov 8, 2005 07:10:58 GMT
5 pts
|
|
Jan,
<quote>
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!
</quote>
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.
|
|
Nov 8, 2005 07:23:35 GMT
5 pts
|
|
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. |
|
|
Jan van den Ende
|
|
Nov 8, 2005 07:51:17 GMT
5 pts
|
|
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 |
|
|
Wim Van den Wyngaert
|
|
Nov 8, 2005 08:24:36 GMT
5 pts
|
|
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 |
|
|
Ian Miller.
|
|
Nov 8, 2005 10:11:48 GMT
5 pts
|
|
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. |
|
|
Cass Witkowski
|
|
Nov 9, 2005 17:13:03 GMT
5 pts
|
|
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
|
|
Nov 10, 2005 01:05:22 GMT
5 pts
|
|
> 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
|
|
Nov 10, 2005 11:26:32 GMT
5 pts
|
|
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
|
|
Nov 10, 2005 11:31:35 GMT
5 pts
|
|
I think HP Data Protector can do it now, but there is a 'little bit' more involved than just entering:
$ backup ... |
|
|
Guy Peleg
|
|
Nov 10, 2005 11:38:51 GMT
10 pts
|
|
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 |
|
Printable version
