|
Home > Archive > Solaris General > August 2007 > Restoring Old Backup without Index
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Restoring Old Backup without Index
|
|
| Hameed 2007-07-26, 1:19 am |
| 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
| |
| Richard B. Gilbert 2007-07-26, 1:19 am |
| 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.
| |
| Hameed 2007-07-26, 1:19 am |
| On Jul 26, 1:08 pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> Hameed wrote:
>
>
>
>
>
>
>
>
> 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)
| |
| Atro Tossavainen 2007-07-26, 1:19 am |
| "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
| |
| Atro Tossavainen 2007-07-26, 1:19 am |
| 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/...74/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
| |
| Hameed 2007-07-26, 1:19 am |
| 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...
| |
| Richard B. Gilbert 2007-07-26, 1:21 pm |
| Atro Tossavainen wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>
>
>
> Legato Networker Save/Restore, also known as Sun Enterprise Backup
> (formerly Solstice Backup).
>
>
>
>
> 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!
| |
| Doug McIntyre 2007-07-26, 1:21 pm |
| "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Atro Tossavainen wrote:
....[vbcol=seagreen]
[vbcol=seagreen]
>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.
| |
| Atro Tossavainen 2007-07-27, 7:21 pm |
| "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
| |
| Richard B. Gilbert 2007-07-27, 7:21 pm |
| Atro Tossavainen wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>
>
>
>
> We seem to average something over 7 TB every month, and our system is
> fairly small compared to what the entire uni does.
>
>
>
>
> 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.
>
>
>
>
> 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.
| |
| Darren Dunham 2007-08-02, 1:20 pm |
| Hameed <Srishk@gmail.com> wrote:
> Is there a way to merge the two set of index? Any kind of help would
> be appreciated.
You can merge the current index with older data from tape with 'nsrck -L7'
for the particular client.
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
| |
| Jyrki Havia 2007-08-17, 1:21 pm |
| Atro Tossavainen <Atro.Tossavainen+news@helsinki.finland.invalid> writes:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
[vbcol=seagreen]
> We seem to average something over 7 TB every month, and our system is
> fairly small compared to what the entire uni does.
Somewhat more on unix-side:
Backup kuukausitilasto luokittain vuodelta 2007 (gigatavuja)
Monthly backup stats from year 2007 (gigabytes)
class / month 1 2 .. 6 7 8 YEAR TOTAL
asenukset 0 0 .. 0 0 0 0
atk-mikroverkko SuSE 0 0 .. 18 14 0 66
autentikointi 133 98 .. 159 177 69 1083
dawa 1492 1273 .. 858 871 681 7790
elainsairaala 302 316 .. 380 390 394 2199
fsecure update 100 124 .. 94 89 42 762
fysiikka 542 302 .. 1706 904 131 5788
fysiikka x-ray lab 737 473 .. 270 26 1373 4320
geofysiikka 270 496 .. 352 328 325 3290
geologia 115 115 .. 11 119 5 920
henkilosto-osasto 0 0 .. 3 3 3 11
hip 356 220 .. 500 525 101 3033
kasvat. 76 72 .. 73 82 63 584
kemia 174 311 .. 225 321 203 2235
kemia ruots. 119 137 .. 115 111 104 906
kiihdytinlabra 767 435 .. 839 1339 183 6833
kirjasto 419 320 .. 1266 593 240 4299
kumpulan unix 59 62 .. 53 91 38 480
kvestuuri 0 0 .. 12 17 3 42
liikuntatoimisto 2 3 .. 1 2 1 14
ling 73 88 .. 65 39 9 534
linux työas. 24 79 .. 33 26 21 265
logit (tl & ux) 488 436 .. 643 622 416 4812
mail imap 5480 5498 .. 7333 11819 4181 58979
mail raja 186 182 .. 159 159 120 1322
mail spam 131 141 .. 168 159 62 1121
mail unix 1066 1102 .. 1190 1201 702 8839
mail virus 41 7 .. 0 0 0 48
matematiikka 95 98 .. 169 206 49 970
meteorologia 1709 1713 .. 2043 1480 1795 13421
myynti 0 0 .. 274 21 28 407
news 16 15 .. 13 16 9 115
nimipalvelu 16 14 .. 14 14 11 111
oodi 750 522 .. 1141 1272 714 6746
otk aleksi 1880 1598 .. 1946 2340 1269 14480
personal 107 101 .. 160 85 75 903
portal 480 372 .. 359 316 304 2836
tietokannat 1019 999 .. 992 1116 644 7889
tietoliikenne 256 159 .. 152 182 76 1339
unix backup koneet 525 541 .. 542 724 266 4199
vallilan unix 1535 1303 .. 2235 1825 824 12057
videoneuvottelu 0 0 .. 3 2 0 5
vmware alustat 1 6 .. 7 8 3 50
webct ym. 787 1190 .. 587 814 495 5785
webhotelli 46 46 .. 51 83 22 402
www 257 407 .. 382 588 136 3372
INVALID 0 0 .. 0 0 0 0
TOTAL 22631 21374 .. 27596 31117 16194 195661
--
Jyrki.Havia@Helsinki.FI, university of Helsinki, Computing Centre
| |
| Atro Tossavainen 2007-08-20, 7:55 am |
| havia@cc.helsinki.fi (Jyrki Havia) writes:
> [I] wrote:
>
> Monthly backup stats from year 2007 (gigabytes)
>
> class / month 1 2 .. 6 7 8 YEAR TOTAL
....
> TOTAL 22631 21374 .. 27596 31117 16194 195661
I'm surprised - that's only ~3 times the amount we do...
Where's my Disk Extender and multiply redundant tape drive locations? 
--
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
| |
| Jyrki Havia 2007-08-23, 1:28 pm |
| Atro Tossavainen <Atro.Tossavainen+news@helsinki.finland.invalid> writes:
> havia@cc.helsinki.fi (Jyrki Havia) writes:
[vbcol=seagreen]
> ...
[vbcol=seagreen]
> I'm surprised - that's only ~3 times the amount we do...
You are propably backing up too much :-)
(No, there is NOT such a thing as "backing up too much"!).
--
Jyrki.Havia@Helsinki.FI, university of Helsinki, Computing Centre
|
|
|
|
|