Does it really matter what the browse time is as long as you have the
tape? I would suggest placing the files in a suitably named directory
that would be meaningful for perpetuity and then back up that directory.
Maybe you could lighten the burden by creating several such named
directories. We have a lot of static data around here, and we break up
large chunks by creating directories with year names, for example. You
could then create a recursive directory listing (/bin/ls -lR dir) of
each and back these up as well. If you forget what files are in which
path, you could always recover the directory listings which would be
small.

When we do these one-time backups, we write them to a special pool that
is not subject to recycling and we normaly do not update the client's
online index. The saveset will always be recoverable via saveset recover
as long as we still have the tape. Even if someone removed the volume
entry, we could always scan the tape. A suitably named directory path
will tell us what was in that directory. Of course, if you must have
complete browse capablity down to the file level for those files, then
yeah, I guess you would be talking about extending the browse policy to
a rather lengthy period. I just don't see that it's necessary to go that
route, though, particularly given the fact that there might be a lot of
other stuff on the affected client that you don't care to keep in the
index that long.

Does anyone know if different instances of the same client can have
different browse policies? Or, does the same policy apply to all the
same instances. What about retention policy?

George

Bar?? Yeter wrote:
>
> Hi,
>
> We want to hold 100,000 files forever. But we have no archive module.
> Is there a way to simulate this?
>
> If I set browse-time to 10 years for specific client & for specific save
> set, does all the other save-sets's browse time of this client affected?
> Does Other pools belong to this client affected?
>
> Ps: 100 000 files will be backed up to special pool.
>
> Thanks.
>
> -----Original Message-----
> From: Stan Horwitz [mailto:stan AT temple DOT edu]
> Sent: Tuesday, March 18, 2003 5:15 PM
> To: Legato NetWorker discussion; BarıÅ? Yeter
> Subject: Re: [Networker] Save Set Recover
>
> On Tue, 18 Mar 2003, [iso-8859-9] Barýþ Yeter wrote:
>
> >Hi,
> >
> >            I have a question. Suppose that I have 100 000 files in a
> >backup. I am trying to restore 5 files out of them.
> >
> >            I want to restore files vi save set recover. Is there any
> >disadvantage for this? Does it scan whole tape to find specified files?
>
> Yes, the entire tape will be scanned. If the saveset is still browsable,
> its probably easier to recover those five file in the standard manner
> rather than via a saveset recover.
>
> Bu mesaj ve onunla iletilen tüm ekler gönderildigi kisi ya da kuruma özel 
> ve Bankalar Kanunu geregince, gizlilik yükümlülügü tasiyor olabilir. Bu 
> mesaj, hiçbir sekilde, herhangi bir amaç için çogaltilamaz, yayinlanamaz 
> ve para karsiligi satilamaz; mesajin yetkili alicisi veya alicisina 
> iletmekten sorumlu kisi degilseniz, mesaj içerigini ya da eklerini 
> kopyalamayiniz, yayinlamayiniz, baska kisilere yönlendirmeyiniz ve mesaji 
> gönderen kisiyi derhal uyararak bu mesaji siliniz. Bu mesajin içeriginde ya 
> da eklerinde yer alan bilgilerin dogrulugu, bütünlügü ve güncelligi 
> Bankamiz tarafindan garanti edilmemektedir ve bilinen virüslere karsi 
> kontrolleri yapilmis olarak yollanan mesajin sisteminizde yaratabilecegi 
> zararlardan Bankamiz sorumlu tutulamaz.
>
> This message and the files attached to it are under the privacy liability in 
> accordance with the Banking Law and confidential to the use of the individual 
> or entity to whom they are addressed. This message cannot be copied, 
> disclosed or sold monetary consideration for any purpose. If you are not the 
> intended recipient of this message, you should not copy, distribute, disclose 
> or forward the information that exists in the content and in the attachments 
> of this message; please notify the sender immediately and delete all copies 
> of this message. Our Bank does not warrant the accuracy, integrity and 
> currency of the information transmitted with this message. This message has 
> been detected for all known computer viruses thence our Bank is not liable 
> for the occurrence of any system corruption caused by this message.
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=