a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-(
b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare.
c) We have a Gigabit network connection, so the 7MB/sec does seem slow.
-----Original Message----- From: Louis Brune [mailto:lbrune@sd.us.am.ericsson.se] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters@mathworks.com Subject: Re: Optimal volume size
Fortunately for me, someone else here takes care of backups, but...
We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger.
Can you not back up with qtree granularity instead of per volume?
b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks.
You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group.
c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer.
Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad.
--
Louis
RE: Optimal volume sizeHi guys,
Backuping on a qtree level gives one very important advantage in case of disaster recovery:
You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last.
Regards, Eli ----- Original Message ----- From: Clarke, John L. (CIS) To: 'toasters@mathworks.com' Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size
a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-(
b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare.
c) We have a Gigabit network connection, so the 7MB/sec does seem slow.
-----Original Message----- From: Louis Brune [mailto:lbrune@sd.us.am.ericsson.se] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters@mathworks.com Subject: Re: Optimal volume size
Fortunately for me, someone else here takes care of backups, but...
We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger.
Can you not back up with qtree granularity instead of per volume?
b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks.
You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group.
c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer.
Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad.
--
Louis