T.R | Title | User | Personal Name | Date | Lines |
---|
480.1 | We are using newer tape drives... | HEWIE::RUSSELL | HAL -> IBM; VMS -> Windows/NT | Mon Jul 13 1992 18:01 | 22 |
| We recently started using TF857 tape drives (the high capacity TK70 replacements)
that allow for very high capacities to be backed up.
This is in place of the previous HSC backups to the TA90's.
One of the benefits of this is that we now do file structured backups, and so
no longer have to restore an entire disk to get a file back, as the backups
are done with the machine actually up and running. (but running minimum).
The downside is that this takes longer, so the machines go down at 5:30pm.
As the procedures are improved, we may be able to push this time back, but not
at the moment.
Since the backups are scheduled in advance, then if you need to work, you
can easily switch over to some of the other systems. For example, almost
everyone now has a workstation (those based at SBP, anyway...), and there are
two other clusters staying up.
Does anyone else think 5:30 is unreasonable?
Peter.
|
480.2 | | FUTURS::WATSON | Rik Watson | Tue Jul 14 1992 09:49 | 6 |
| Yes: 5:30 is unresonable.
I would expect backups to start at 7:30 to 8:00 pm.
(Or even better during the weekend)
To do otherwise is a false economy.
|
480.3 | | SED750::CLARKE | | Tue Jul 14 1992 10:34 | 10 |
| The workstation & other systems point is not really relevant;
- If I'm working on a project; I have all my development files on one
cluster.
- If my software talks to other systems on a cluster (e.g. XCS & AQS)
then using another cluster when mine isn't available doesn't help.
- Been asking for a workstation for years, I'm unlikely to get one soon,
as opposed to you lucky people at SBP.
|
480.4 | Backups inconvenient ! | CURRNT::DAW | Pizzazz-man | Tue Jul 14 1992 17:55 | 22 |
|
Just to add my two-penneth,
Yes it is inconvenient for the backups to start at 5.30. They always
appear to be happening on the machine I'm doing my development on.
Copying files to other clusters/workstations is all well and good, but
if you need to link againt a 2Mbyte object library (slight
exaggeration), you're hardly going to copy that over as well !
In the case of Support, it is inconvenient that the Call-handling
machine goes down at 5.30 - the problems/solutions and symptoms/
solutions database is then unavailable until at least 9.00 a.m. the
next day - although we do have a duplicate call-handling system to
avoid this, i.e. we cannot really provide support after 5.30 on that
day.
If we've invested in new technology, surely we must be somewhere near
lights-out computer rooms - i.e. machines that can stay up nearly all
the time etc...
Wob
|
480.5 | My 2 pence worth | MAJORS::POAD | | Wed Jul 15 1992 11:29 | 15 |
| I too would add my 2 pence worth and say that backups starting at 5:30
is inconvenient.
My development is done on FUTURS and it is not practical to have to
move to another cluster, in fact I didn't have an account on another
cluster until recently.
The thing that gives me the most grief is when I am under pressure to
get something finished and I can't stay late to achieve it cos the
machines are going down. This has happened a number of times.
I would agree that backups starting at 8pm or at weekends would be a
great help here.
Chris
|
480.6 | Sorry - Unlikely to change... | NOSTRL::DAVIES | Close, but no banana. | Tue Sep 08 1992 18:55 | 32 |
|
Well, you've all had a chance to say what you like so now I'll add my waffle
to the end of the list.
The backups currently run from:
17:30 until 07:30 the following day on CURRNT (average)
17:30 until 07:30 the following day on FUTURS (average)
17:30 until 05:30 the following day on PASTIT (average)
All of the above are "UNATTENDED" and [on average :^) ] problem free.
As you can see to move the start times out by two hours eats into the
beginning of the following working day. That doesn't help anyone.
As far as weekend working is concerned: FORGET IT
There is no shortage of people who would like to earn some overtime but
you must be aware pay for overtime is as rare as rocking-horse droppings.
I accept that it's inconvenient, but unreasonable it is certainly not.
As far as PASTIT is concerned:
I intend to improve the availability of this system from the
downtime mentioned above (approx 11 hours) to less than ONE hour.
This will allow much later working on PASTIT - I know it doesn't help the
developers much, but I'm hoping to move both CURRNT and FUTURS towards
the same downtime for BACKUPs as more hardware becomes available.
Keith.
|
480.7 | Still waiting for the 1 hour downtime | SBPEXE::DOUGLASS | Chewing on life's gristle ..... | Wed Mar 24 1993 17:38 | 15 |
| >>As far as PASTIT is concerned:
>> I intend to improve the availability of this system from the
>> downtime mentioned above (approx 11 hours) to less than ONE hour.
>>This will allow much later working on PASTIT - I know it doesn't help the
>>developers much, but I'm hoping to move both CURRNT and FUTURS towards
>>the same downtime for BACKUPs as more hardware becomes available.
Any news on this Keith ?
Paul (with_the_hump_cos_he's_just_been_kicked_off_PASTIT_again)
|