If you are still looking at compression and WAN back-up solutions, take a
look at Quark+ and NBCOPY from Quest Software.
This combination allows you to deploy a WAN backup solution over the network
without NS/3000 services. HEWLETT-PACKARD themselves have used this for
years in the background to move and collect remote backups to a central
location. We would be happy to participate in your benchmark. Additionally,
try to :RESTORE the files in your FTP test without changing the accounting
structure and capabilities. I think you will see that the default account
and capabilities are provided not what was the disk prior to the :STORE.
Call 1-800-306-9329 or e-mail: [log in to unmask] Subject: MPE Quark+/NBCOPY
WAN backup
-----Original Message-----
From: James Hofmeister [mailto:[log in to unmask]]
Sent: Tuesday, March 18, 2003 7:41 AM
To: [log in to unmask]
Subject: back up solution for 3000 and rest of network
Hello @ 3000-l,
RE: back up solution for 3000 and rest of network
I have been looking at FTP/iX performance and backups and have found
the combination of store-to-disk with compression and binary ftp
transfers over 100BT links can be a useful solution but it has
serious limits for large systems.
I use this combination to backup the files "modified" minus DATABASE
on my systems. DATABASE should not be backed up based on "modify"
dates of file sets, they should be backed up as a unit.
store @[log in to unmask]@[log in to unmask];*backup;date>=03/01/03;compress;show
I update the date to current when I perform a full system backup.
My down time is the length of time it takes to perform the store-to-
disk and for store to release the lock on the files. My system is
available during the period of time when the FTP is performing a copy
to a remote backup/file server.
In my test of a "PUT" on an A-Class (e3000/A400-100-11) 2176 Mb
memory w/7.5 to a Kayak XA 333Mz 128Mb memory w/NT 4.0 SP 6. over an
isolated 100BT link running 1/2 duplex with a HP Advance Stack 100BT
hub... (note: both the A-Class and the Kayak PC are idle except for
the FTP test).
01Gb @ 1655 Kbytes/Sec @ 0.18 hours
02Gb @ 1552 Kbytes/Sec @ 0.38 hours
03Gb @ 0843 Kbytes/Sec @ 1.04 hours
04Gb @ 0567 Kbytes/Sec @ 2.07 hours
05Gb @ 0528 Kbytes/Sec @ 2.78 hours
...
10Gb @ 0465 Kbytes/Sec @ 6.31 hours
...
20Gb @ 0441 Kbytes/Sec @ 13.29 hours
YMWV (Your Mileage Will Vary), but you need to keep in mind that if
your STORE-TO-DISC file grows too large that using FTP to copy it to a
remote backup/file server could exceed the period of time you have
before you start your next backup.
--------------------------------------------------
Warning: If you use a non-3000 as your remote
backup/file server a current limit of 4Gb exist on
retrieving the file from the remote/backup file
server. This is as per SR 8606294908 and a
solution is forthcoming.
--------------------------------------------------
Note: Your backup is not complete until you have safely completed your
FTP to a remote backup/file server. Until then your only backup is on
the disk that you are attempting to protect by performing a backup.
i.e. If you have a disk failure before the FTP completes, then you
could also loose your backup file as well as the data on that disk.
If you need to compute sectors to Gb...
:listf backup,2
FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
SIZE TYP EOF LIMIT R/B SECTORS #X MX
BACKUP STORE 128W FB 1487351 16776959 1 1487360 * *
note: 1 sector = 256 bytes.
:calc 1487360*256
380764160, $16B20000, %2654400000
380764160 Bytes...
note: 1073741824 bytes = 1Gb
:calc (1487360*256)/1073741824
0, $0, %0
Less than 1Gb. (If I use a calculator I get 0.35Gb).
... and in this example my ftp statistics are:
381175552 bytes sent in 625.76 seconds (594.86 Kbytes/sec)
The dump-to-disk ran for 22 minutes, the FTP ran for less than 11
minutes.
Notes:
--------------------------------------------------
FTP file transfer performance decreases when:
You transfer a file size greater than the limit of
physical system memory.
You transfer a file 4Gb or greater as FTP switches
from short to long pointers when performing moves
& prefetch from disk to memory.
FTP competes against other user processes for CPU,
Memory or Disk I/O.
--------------------------------------------------
I hope this helps
Regards,
James Hofmeister
Hewlett Packard - Global Solutions Engineering (WTEC)
P.S. My Ideals are my own, not necessarily my employers.
________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
