Maybe I can explain it a bit better.
Say you have a client with the following files on day 1
File a
File b
File c
File d
Then a full backup runs at the end of day 1, Legato will have the following
files in the index
File a
File b
File c
File d
During day 2 a new file is added (file e) and a file is deleted (file b). An
incremental backup runs at the end of day 2. Legato now has the following index
Day 1
File a
File b
File c
File d
Day 2
File a
File c
File d
File e
Now, on day 3 two files are deleted (file a and file e) but no backup is run,
Legato will have the following index
Day 1
File a
File b
File c
File d
Day 2
File a
File c
File d
File e
A full backup is run at the end of day 3 and the Legato has the following index
Day 1
File a
File b
File c
File d
Day 2
File a
File c
File d
File e
Day 3
File c
File d
Do you see what's happening? Even though we do fulls and incrementals, the
index is updated in such a way that it reflects the state of the client at the
time of the backup (whether the file was backed up on the last full or the
latest incremental, if it was on the client when the backup ran, it will be in
the index).
All you have to do when restoring is select the browse time.
Does that answer your question?
I don't think it's a problem but, if you think it is, can you explain how it is
a problem so that I can see what your concerns are.
Regards
Bob
-----Original Message-----
From: Yura Pismerov [mailto:ypismerov AT tucows DOT com]
Sent: 24 April 2003 17:31
To: Legato NetWorker discussion; Wood, R A (Bob)
Subject: Re: [Networker] Trouble with recovering
"Wood, R A (Bob)" wrote:
>
> Hi,
> That is Networker 'working as designed' - you can't see the
> files because they weren't there when the backup was run. Even though
> you backed up an incremental, the index for that time shows all files
> that existed on the server AT THE TIME OF THE BACKUP, the list will
> include files that were backed up on the full backup that were not
> deleted or changed (so not backed up on the incremental backup) as
> well as the changed files backed up with the incremental backup.
I have a question. If I used a full backups all the time on that area,
would it show me the files that were deleted in between the full backup runs ?
Or it would show me only the last full backup content ? If it indeed does what
you say, it sounds like a disaster to me (unless it behaves differently in case
of having several periodical full backups). What is the point of having long
browse/retention policy if I am not able to extract a file that was deleted at
some point ?
>
> Trust me, Networker is a lot easier to get on with if you
> don't try to make it do things it is not designed to. Have a think
> about it, do you really want to see all files that have existed since
> the last backup? What about a restore, you restore a folder from a
> certain date and a user complains that you've restored a file that was
> deleted several days before that date. It's a minefield you're
> straying into. Beware....
>
> Bob.
>
>
> -----Original Message-----
> From: Yener KiliГ [mailto:yenki AT KOCBANK.COM DOT TR]
> Sent: 24 April 2003 16:04
> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
> Subject: [Networker] Trouble with recovering
> Importance: High
>
> Hi,
> We have a restoring situation here.
>
> We backed up large amounts of files in a directory (20 years browse
> and retension time). Then we delete those files. Afterwards, we added
> new files ( completely different files) to the same directory and done
> an we then done an incremental backup. This incremental backup spread
> a new a volume. Somehow ( we did some operations, cloning and removing
> clonned volume.) above (full and one inremental) two save sets became
> revorable. We then remove and scan those volumes by using scanner
> command.
>
> When we try to restore files in full backup, we cannot restore them (
> recover command cannot find files in index db). It only gives us file
> in incremental backup. We need to change browse time to get files in
> full backup. However we don't want to behave like that. Recover
> command be able to restore all files without changing browse time. How
> can we do that?
>
> Thanks in advance.
>
> Best regards,
>
> Yener KILIг
>
>
>
> KOгBANK A.╙.
> Sistem Teknoloji / Sistem Destek
> yenki AT kocbank.com DOT tr
> +90 216 454 06 00, ext. 4639
>
> 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Yuri Pismerov, Sr. System Administrator,
TUCOWS.COM INC. (416) 535-0123 ext. 1352
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
