Hi everyone,

I am very new to this so please bear with me while I explain.

I am trying to restore an old backup and have problem with index.

I'll give you some background info:
Some time ago before I started working here they moved from server1 to
server2 and migration was successful however it seems that the backup
index was not properly migrated. So now when trying to restore backups
that were done prior to migration, it says that there is no index for
that date/time.

I checked the index and it seems that when it was move, it was moved
to the wrong location

So there is /nsr/index/server2/db6/ and then there is another server2
folder under server2: /nsr/index/server2/server2/db6

Is there a way to merge the two set of index? Any kind of help would
be appreciated.

We are running solaris 9

Hameed wrote:
> Hi everyone,
>
> I am very new to this so please bear with me while I explain.
>
> I am trying to restore an old backup and have problem with index.
>
> I'll give you some background info:
> Some time ago before I started working here they moved from server1 to
> server2 and migration was successful however it seems that the backup
> index was not properly migrated. So now when trying to restore backups
> that were done prior to migration, it says that there is no index for
> that date/time.
>
> I checked the index and it seems that when it was move, it was moved
> to the wrong location
>
> So there is /nsr/index/server2/db6/ and then there is another server2
> folder under server2: /nsr/index/server2/server2/db6
>
> Is there a way to merge the two set of index? Any kind of help would
> be appreciated.
>
> We are running solaris 9
>

What the hell is a "backup index"? What are you using to do your
backups? It doesn't seem to be "ufsdump".

FWIW, I don't think I'd want to trust my backups to anything that needed
more than the backup file and the backup/restore program.

On Jul 26, 1:08 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> Hameed wrote:
> > Hi everyone,
>
> > I am very new to this so please bear with me while I explain.
>
> > I am trying to restore an old backup and have problem with index.
>
> > I'll give you some background info:
> > Some time ago before I started working here they moved from server1 to
> > server2 and migration was successful however it seems that the backup
> > index was not properly migrated. So now when trying to restore backups
> > that were done prior to migration, it says that there is no index for
> > that date/time.
>
> > I checked the index and it seems that when it was move, it was moved
> > to the wrong location
>
> > So there is /nsr/index/server2/db6/ and then there is another server2
> > folder under server2: /nsr/index/server2/server2/db6
>
> > Is there a way to merge the two set of index? Any kind of help would
> > be appreciated.
>
> > We are running solaris 9
>
> What the hell is a "backup index"? What are you using to do your
> backups? It doesn't seem to be "ufsdump".
>
> FWIW, I don't think I'd want to trust my backups to anything that needed
> more than the backup file and the backup/restore program.- Hide quoted text -
>
> - Show quoted text -

Solstice backup (nsr)

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

> What the hell is a "backup index"? What are you using to do your
> backups? It doesn't seem to be "ufsdump".

Legato Networker Save/Restore, also known as Sun Enterprise Backup
(formerly Solstice Backup).

> FWIW, I don't think I'd want to trust my backups to anything that needed
> more than the backup file and the backup/restore program.

I gather you're not backing up a large amount of data, then, and
that you've probably never used an autochanger.

--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

Hameed <Srishk@gmail.com> writes:

> index was not properly migrated. So now when trying to restore backups
> that were done prior to migration, it says that there is no index for
> that date/time.
>
> I checked the index and it seems that when it was move, it was moved
> to the wrong location
>
> So there is /nsr/index/server2/db6/ and then there is another server2
> folder under server2: /nsr/index/server2/server2/db6
>
> Is there a way to merge the two set of index? Any kind of help would
> be appreciated.

I probably wouldn't. In the generic case, you can run "scanner" to
rebuild the index for volumes.

http://download.oracle.com/docs/cd/A...4/appendix.htm

I hope it's not a very large amount of unindexed tapes you're left
with.

If you have a support contract with Sun, you could always ask them
for clues. That's what I would do if I were in your position.

--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

Thanks Atro. I will go with scanning option. I have a large number of
them to do. I guess I will scan them based on need. Right now I have
about 11 tapes to scan...

Atro Tossavainen wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>
>>What the hell is a "backup index"? What are you using to do your
>>backups? It doesn't seem to be "ufsdump".
>
>
> Legato Networker Save/Restore, also known as Sun Enterprise Backup
> (formerly Solstice Backup).
>
>
>>FWIW, I don't think I'd want to trust my backups to anything that needed
>>more than the backup file and the backup/restore program.
>
>
> I gather you're not backing up a large amount of data, then, and
> that you've probably never used an autochanger.
>

About 180GB is the largest I've ever done. It wasn't Unix but I used a
tape drive with a "stacker". The stacker could be programmed but it
defaulted to using the tapes "in order" which is the way we used it.

So that "index" is a catalog of which files were backed up and which
tape they were written to?

I've restored a whole disk farm as part of a disaster recovery exercise
or a whole disk when I had a hardware failure but I think it has been
about twenty years since I needed to restore a single file!

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Atro Tossavainen wrote:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>>
>>>What the hell is a "backup index"? What are you using to do your
>>>backups? It doesn't seem to be "ufsdump".
....
>>>FWIW, I don't think I'd want to trust my backups to anything that needed
>>>more than the backup file and the backup/restore program.
>>
>>
>> I gather you're not backing up a large amount of data, then, and
>> that you've probably never used an autochanger.
>>

>About 180GB is the largest I've ever done. It wasn't Unix but I used a
>tape drive with a "stacker". The stacker could be programmed but it
>defaulted to using the tapes "in order" which is the way we used it.

>So that "index" is a catalog of which files were backed up and which
>tape they were written to?

Yes, exactly. The index is the directory of all files and which
versions are stored on which tape and at which position on the tape.
enterprise software does use tapemarks.

So, rather than the process of feed tape in, read the whole tape in
looking to see if thats the right file you need... You instead startup
the restore console, browse down to the file and version you need. It
tells you to insert tape x of the set, it does a seek on the tape to
that subset and pulls that file off.

Rather than watching the tape drive spin for an hour or longer,
the tape drive seeks to the specific tapemark which takes minutes, and you have
your file restored in 10-15 minutes. Its really slick to be able to
restore that quickly.

If the index is blown away or expired, you have to reindex the whole
tapes in all the tape set. Takes forever. Some systems can still restore
things without the index, you just don't get the speed and convience,
you fall back to searching each tape in the set and searching through
the whole tape for what you need. I don't remember if Legato operated
that way or not.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

> About 180GB is the largest I've ever done.

We seem to average something over 7 TB every month, and our system is
fairly small compared to what the entire uni does.

> It wasn't Unix but I used a tape drive with a "stacker". The stacker
> could be programmed but it defaulted to using the tapes "in order"
> which is the way we used it.

Most autochangers have barcode readers that allow you to identify tapes
(labeled with barcode stickers, obviously) without having to read their
contents. Combined with an online index to tell you which tapes contain
which backup sets (and files), figuring out which tape the autochanger
should insert in the drive to restore any particular file is just a tad
quicker than having to read through entire tape sets.

> I've restored a whole disk farm as part of a disaster recovery exercise
> or a whole disk when I had a hardware failure but I think it has been
> about twenty years since I needed to restore a single file!

Besides not having disk crashes, you also don't have badly behaved
programs that corrupt files, nor users who accidentally delete them,
then. (And you always arrange your disk arrays in such perfect
ways to begin with that you never need to do a complete save, rebuild
a better arrangement, and restore, either.)

As an aside, being able to mount snapshots of file systems has
considerably reduced my frequency of going to tape for backups.
If folks are able to figure out within the same day that they've
accidentally lost something they can just get it from the snapshot
themselves without admin intervention.

--
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS

Atro Tossavainen wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>
>>About 180GB is the largest I've ever done.
>
>
> We seem to average something over 7 TB every month, and our system is
> fairly small compared to what the entire uni does.
>
>
>>It wasn't Unix but I used a tape drive with a "stacker". The stacker
>>could be programmed but it defaulted to using the tapes "in order"
>>which is the way we used it.
>
>
> Most autochangers have barcode readers that allow you to identify tapes
> (labeled with barcode stickers, obviously) without having to read their
> contents. Combined with an online index to tell you which tapes contain
> which backup sets (and files), figuring out which tape the autochanger
> should insert in the drive to restore any particular file is just a tad
> quicker than having to read through entire tape sets.
>
>
>>I've restored a whole disk farm as part of a disaster recovery exercise
>>or a whole disk when I had a hardware failure but I think it has been
>>about twenty years since I needed to restore a single file!
>
>
> Besides not having disk crashes, you also don't have badly behaved
> programs that corrupt files, nor users who accidentally delete them,
> then.

My users were all "captive"! The LOGIN.COM put them into the
application and logged them out when they exited the application. They
had very little scope for getting into trouble!
(And you always arrange your disk arrays in such perfect
> ways to begin with that you never need to do a complete save, rebuild
> a better arrangement, and restore, either.)

I've backed up and restored an entire system both for disaster recovery
exercise and for migrating our application and data to new hardware.

We also had a Storage Technology Robot that used bar codes to identify
tapes. I used it for some database backups with Netbackup. I used a
locally attached drive for system backups. If I had used Netbackup, it
would have added several hours to a restore during a disaster recovery
situation; we would have had to build/restore a netbackup server before
we could restore the production system.