| Author |
FTP to/from UBUNTU LINUX |
somersdave
Member
Posts: 67
Location: bristol,UK
Joined: 23.03.07 |
| Posted on November 14 2011 08:28 |
|
|
With the aim of getting a full system image backup copied to safety (I had a bit of a scare with the RAID system on my Alpha4000 when trying to use the second disk shelf) I've been trying to FTP BACKUP SAVESETS to my PC running UBUNTU.
just trying a few files with the FTP BINARY option I get the following PROBLEM when trying to list the files in the saveset returned from PC. I execute the FTP GET and PUT commands from the PC end.
$ back/lis dave_exe_ret.bck/save
Listing of save set(s)
%BACKUP-E-POSERROR, error positioning SYS$SYSDEVICE:[USER.DAVE]dave_exe_ret.bck;
1
-RMS-F-IOP, operation invalid for file organization or device
%BACKUP-E-READERRS, excessive error rate reading SYS$SYSDEVICE:[USER.DAVE]dave_e
xe_ret.bck;1
-BACKUP-E-BLOCKCRC, software block CRC error
%BACKUP-I-OPERSPEC
%BACKUP-I-OPERASSIST, operator assistance has been requested
Interrupt
$ back/lis/nocrc dave_exe_ret.bck/save
Listing of save set(s)
%BACKUP-E-INVBLKSIZE, invalid block size in save set
%BACKUP-E-INVRECSIZ, invalid record size in save set
Save set: DAVE_EXE.BCK
Written by: SYSTEM
UIC: [000001,000004]
Date: 14-NOV-2011 16:53:29.56
Command: BACKUP/VERI *.EXE;,*.OLB; DAVE_EXE.BCK/SAVE
Operating system: OpenVMS Alpha version V8.3
BACKUP version: V8.3
CPU ID register: 80000000
Node name: _ALPHA1::
Written on: _ALPHA1$DRA0:
Block size: 32256
Group size: 10
Buffer count: 96
%BACKUP-E-INVRECSIZ, invalid record size in save set
%BACKUP-E-INVBLKSIZE, invalid block size in save set
%BACKUP-E-INVRECSIZ, invalid record size in save set
%BACKUP-E-INVBLKSIZE, invalid block size in save set
%B
etc. etc
this log is generated which suggests that I might need MULTINET ?
$ ty TCPIP$FTP_SERVER.LOG;2
$ Set NoOn
$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY" ) )
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\MULTINET\
%SET-W-NOTSET, error modifying DRA0:
-SET-E-INVDEV, device is invalid for requested operation
etc,etc
the original .BCK has:
Record format: Fixed length 32256 byte records
the returned .BCK has:
Record format: Fixed length 512 byte records
Perhaps I could use FDL to modify the returned file?
Any suggestions please? |
|
|
| Author |
RE: FTP to/from UBUNTU LINUX |
brad
Member
Posts: 134
Location: Hopedale, MA USA
Joined: 15.12.05 |
| Posted on November 14 2011 14:48 |
|
|
|
If you don't mind the extra step, ZIP up the backup save_set on VMS, (remember to use -V) and then FTP in binary mode. As long as you ZIP and UnZIP using the VMS file attributes switch, you can move the ZIPPped up save_set any place you wish. |
 |
| Author |
RE: FTP to/from UBUNTU LINUX |
martinv2
Member
Posts: 107
Location: Goslar, Germany
Joined: 02.10.07 |
| Posted on November 14 2011 19:17 |
|
|
This problem is so common that there's a DCL procedure to negate the negative effects FTP has on backup savesets. Available e.g. at http://www.digiater.nl/openvms/freeware/v80/000tools/reset_backup_saveset_file_attributes.com
Or you can follow Brad's sound advice and ZIP your savesets.
HTH
Martin
http://de.openvms.org/martinv/ |
|
|
| Author |
RE: FTP to/from UBUNTU LINUX |
somersdave
Member
Posts: 67
Location: bristol,UK
Joined: 23.03.07 |
| Posted on November 16 2011 07:17 |
|
|
Thanks both, for the advice; I'll probably try something weekend but in the mean time will try to assess any possible effects of copying a BIG file to my PC disk (80GB total but partitioned)
I found the SET FILE/ATTRIBUTE command interesting. I think the last VAX VMS I used was v5.5 and can't remember what Alpha (before 8.3) version (which I guess would have had the command) (it's definitely not in the late 80s VMS 5.0 general user manual, I kept when it was being junked)
Here's some more discussion of the problem and solutions (and specifies the command program Martin has given). It says the particular command was introduced at VAX VMS 6.0
http://antinode.info/dec/sw/fixrec.html
Edited by somersdave on November 16 2011 07:21 |
|
|
| Author |
RE: FTP to/from UBUNTU LINUX |
somersdave
Member
Posts: 67
Location: bristol,UK
Joined: 23.03.07 |
| Posted on November 22 2011 07:52 |
|
|
I seem to have successfully got a saveset of the alpha4000 raid disk copied to my Linux PC. I had a partition of about 19GB on the PC, to which the UBUNTU system had read/write access:
//media/New Volume - I used the "SYSTEM - ADMINISTRATION - DISK UTILITY" to rename the "New Volume" to "backup" after 'UNMOUNTING' the volume, as I could specify New* but not "New Volume"
- to be honest, the VMS commands seem much more friendly, logical and self-explanatory (but I'm biased)
The interesting thing about the backup/transfer process was how fast the FTP transfer of the 2.6 GB saveset to the PC (about 10 mins I think) over ethernet to the PC relative to the backup time of about 2 hours:
backup/image/verify alpha1$dra0: alpha4000.bck/save
I copied the file back to the Alpha which took much longer than the original FTP. and
even making a copy on the Alpha took a long time (I think about an hour?), despite the RAID disk having plenty of free space. (Must try to learn more about disk I/O - reads faster than writes? - , internal bus speeds and ethernet - maybe some, possibly security overhead, had an impact? but I suppose accessing modern disks will be faster, anyway)
several files were 'marked' as NOBACKUP and not saved: net$proxy.dat, pagefile.sys, etc. and some verification errors for SYSUAF.DAT and access conflicts for various .LOG files.
The ZIP.EXE file I got from a link on the HP site gave some problem (didn't note) so I just ran
the Reset File Attributes command file to process the saveset I had copied back from the PC - this was pretty instantaneous - so I suppose only the file header info. is being changed. I could then backup/list the contents of the returned file. (perhaps the ZIP.EXE needs be processed as I used FTP)
Sorry to interrupt the discussion of the value of the Hobbyist Program to HP (don't upset them  )
Edited by somersdave on November 22 2011 07:57 |
|
|
| Author |
RE: FTP to/from UBUNTU LINUX |
brad
Member
Posts: 134
Location: Hopedale, MA USA
Joined: 15.12.05 |
| Posted on November 22 2011 12:25 |
|
|
|
somersdave wrote:
[...]
The ZIP.EXE file I got from a link on the HP site gave some problem (didn't note) so I just ran
the Reset File Attributes command file to process the saveset I had copied back from the PC - this was pretty instantaneous - so I suppose only the file header info. is being changed. I could then backup/list the contents of the returned file. (perhaps the ZIP.EXE needs be processed as I used FTP)
I haven't checked which version of ZIP/UNZIP is linked from HP, but if you can find SMS' (Antinode) website, he maintains the most up-to-date version of ZIP/UNZIP for VMS (Versions 3+ and 6+, respectively). These versions work fine, and if you're willing to compile and link with the proper options, large file support (>2GB) is available. The site is well-documented, and the utilities have saved my bacon when I accidentally deleted my home directory on my hobbyist Alpha, and had to restore from an off-site (Ubuntu) backup.
RESET_FILE_ATTRIBUTES is a good option, as well. I just think it's nice to have a VMS version of a well-known utility; it shows that VMS can be a viable alternative to mainstream OS platforms. Yet another plus for the VMS Hobbyist program (Bill Pedersen, are you listening?) |
|
|
| Author |
RE: FTP to/from UBUNTU LINUX |
somersdave
Member
Posts: 67
Location: bristol,UK
Joined: 23.03.07 |
| Posted on November 28 2011 11:16 |
|
|
I hadn't specified the IMAGE (or BINARY) option when I used FTP to copy the ZIP.EXE to the Alpha.
Just gone through the same procedure with the alpha 4100 (which is NOT RAID configured - so I have some spare 9GB disks to store savesets.
It looks like the program dates from the late 90's (so I'll try to get the version suggested)
$run zip.exe
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
Zip 2.3 (November 29th 1999). Usage: zip=="$disk:[dir]zip.exe"
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
The default action is to add or replace zipfile entries from list, which
can include the special name - to compress standard input.
etc, etc
I was having some problems with the ZIP operation ( eg: zip error: Zip file structure invalid - probably my fault) but will leave it for now as I copied the saveset to the PC and back and, after using the 'attributes' .COM file could LIST the saveset ok. (not sure if the 'odd' missing file will be a problem - will investigate - if I ever need to restore the whole system) I feel a bit more secure now
Edited by somersdave on November 28 2011 11:16 |
|
|
