Backup Central

Is there an easy way to keep copies of say a month's worth of indexes
for a client, say in an nfs mounted directory nsr-backup.

It's overkill to keep a mirror copy of a years worth of index for a
client, but it might be worth keeping a mirror copy of the last
full + incrementals of a client ??

Is there a utility that can copy bits of the indexes themselves, rather
than getting them from tape ??

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Bill Hewitt wrote:

Is there an easy way to keep copies of say a month's worth of indexes
for a client, say in an nfs mounted directory nsr-backup.

It's overkill to keep a mirror copy of a years worth of index for a
client, but it might be worth keeping a mirror copy of the last
full + incrementals of a client ??

Is there a utility that can copy bits of the indexes themselves,
rather than getting them from tape ??

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

To follow up my own post, what do people do as far as keeping mirror
copies of important files ? The minimum to mirror to get the backup
server back quickly following a disk death would seem to be

1) the mm database
2) the res directory
3) the server indexes


Do people mirror these in general, or rely on recovering from tape ? do
people mirror more of /nsr on the server than this ?

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Bill Hewitt wrote:
Bill Hewitt wrote:

Is there an easy way to keep copies of say a month's worth of indexes
for a client, say in an nfs mounted directory nsr-backup.

It's overkill to keep a mirror copy of a years worth of index for a
client, but it might be worth keeping a mirror copy of the last
full + incrementals of a client ??

Is there a utility that can copy bits of the indexes themselves,
rather than getting them from tape ??

--


To follow up my own post, what do people do as far as keeping mirror
copies of important files ? The minimum to mirror to get the backup
server back quickly following a disk death would seem to be

1) the mm database
2) the res directory
3) the server indexes


The problem with copying these files is that in order to get a
consistent copy you would need to regularly stop NetWorker first, and
that's often not practical in a busy environment.

You do of course have your NetWorker filesystems on mirrored or RAIDed
disks don't you? Better still if you use EMC storage, your NetWorker
filesystems should be SRDF'ed to a remote site.

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

On Tue, 15 Mar 2005, Bill Hewitt wrote:

To follow up my own post, what do people do as far as keeping mirror
copies of important files ? The minimum to mirror to get the backup
server back quickly following a disk death would seem to be

1) the mm database
2) the res directory
3) the server indexes


Do people mirror these in general, or rely on recovering from tape ? do
people mirror more of /nsr on the server than this ?

The NetWorker 7.1.3 server I manage is a Sunfire V480 with Solaris 9.
Connected to this server is a Store Edge A1000 disk array which is devoted
to our entire /nsr disk volume and each physical disk in the array cabinet
is mirrored. This provides a reasonable level of data protection and it
works well. Not long after we put our new server into production, one of
the disks on that A1000 failed and so did a controller. We didn't lose a
single byte of data, nor did we lose any production time. The hardware was
fixed during idle hours and the data on the failed disk drive was not lost
because it was available on its alternate drive.

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu