Facts: each Backupjob has 30 days for Retention and Browse, within this time we do a clone for offset (without index). All Indexes goes automatically to the Default-Pool.
#1a: we would like to increase this to 90 days.
Is this a problem for the Networker DB to hold (space, performance...)?
to get an idea of the capacity requirements, there are ways to calculate an approx size when designing your networker server, but in your case it would just be a matter of seeing how much space your current 30days metadata is utilising, the triple this to get an approx size of a 90 days retention.
you should have no noticable differences in performance etc going from 30day to just 90day retention.
#1b: after this 30 days we're not capable to restore an Index, so the Saveset is browsable
- because I have done a Clone, I think (I'm sure) the nsrck-command always take the saveset from the offset Clonetape! I see this in the Log of the Monitor...
Why, if I have a tape in the library with the files?
Can I tell nsrck to take it from a specific tape?
I have one question for you. If your needing to restore from media that is older than the retention period, why are you using that retention period ?
Why wasnt the retention period configured to meet the business requirements for recoverable data. I know there will always be certain times when a request is made for a restore beyond the retention period, but if its a common scenario, then the backup solution and backup SOE is not correctly designed.
if the tape and contained data is expired and no longer within the client index and media index, as per that document running the scanner -i will read the contents back into networkers CFI and Media index. Another option if you know the saveset id "ssid" and its the whole saveset to be recovered is to run the scanner -S ssid -x uasm -rv command to pipe the scanner command the the recover command.
if you are cloning the tape and the retention periods for the clone tape are the same as the primary backup, then they too also expire within that retnetion period, but you can set a different media retention period for the Clone pool and this will ensure the Clone tape is still "completed"/"recoverable" "cr" sumflags, and a saveset restore is still an option using "recover -S"
using the nsrck -L7 command will over-write your existing Client index, it will not merge them.
#2: Rebuild Index with scanner
Facts: we have a Windows-server with paths that are deeper than 256 characters. The backup goes well, but "often" we can't restore files.
#2a: If we make a redirected restore, it asks if we want to overwrite! But it is a new path without any files in it! Half of the files are restored, but we have files with a point at the start and files with umlaut are kryptographic.
cfaller
96 Posts
0
January 13th, 2010 22:00
#1: Retention and Browse Policy
Facts: each Backupjob has 30 days for Retention and Browse, within this time we do a clone for offset (without index). All Indexes goes automatically to the Default-Pool.
#1a: we would like to increase this to 90 days.
Is this a problem for the Networker DB to hold (space, performance...)?
to get an idea of the capacity requirements, there are ways to calculate an approx size when designing your networker server, but in your case it would just be a matter of seeing how much space your current 30days metadata is utilising, the triple this to get an approx size of a 90 days retention.
you should have no noticable differences in performance etc going from 30day to just 90day retention.
#1b: after this 30 days we're not capable to restore an Index, so the Saveset is browsable
- I've tried to do it belong to this article https://solutions.emc.com/emcsolutionview.asp?id=esg91975
- because I have done a Clone, I think (I'm sure) the nsrck-command always take the saveset from the offset Clonetape! I see this in the Log of the Monitor...
Why, if I have a tape in the library with the files?
Can I tell nsrck to take it from a specific tape?
I have one question for you. If your needing to restore from media that is older than the retention period, why are you using that retention period ?
Why wasnt the retention period configured to meet the business requirements for recoverable data. I know there will always be certain times when a request is made for a restore beyond the retention period, but if its a common scenario, then the backup solution and backup SOE is not correctly designed.
if the tape and contained data is expired and no longer within the client index and media index, as per that document running the scanner -i will read the contents back into networkers CFI and Media index. Another option if you know the saveset id "ssid" and its the whole saveset to be recovered is to run the scanner -S ssid -x uasm -rv command to pipe the scanner command the the recover command.
if you are cloning the tape and the retention periods for the clone tape are the same as the primary backup, then they too also expire within that retnetion period, but you can set a different media retention period for the Clone pool and this will ensure the Clone tape is still "completed"/"recoverable" "cr" sumflags, and a saveset restore is still an option using "recover -S"
using the nsrck -L7 command will over-write your existing Client index, it will not merge them.
#2: Rebuild Index with scanner
Facts: we have a Windows-server with paths that are deeper than 256 characters. The backup goes well, but "often" we can't restore files.
#2a: If we make a redirected restore, it asks if we want to overwrite! But it is a new path without any files in it! Half of the files are restored, but we have files with a point at the start and files with umlaut are kryptographic.
Why?
#2b: belong to https://solutions.emc.com/emcsolutionview.asp?id=esg54197 we tried first to
- recover -iY -d "e:\restore" -S 3726371882 "E:\paht to the user date\long\long\why it is not summer and so on\number 1\and 2\file with comments.txt"
with no success, like problem #2a
- scanner -i -S ssid drive_name -> after that we had no index any more!
why?
you are performing a saveset recovery here, you cant specify the directory or data to recover...
a saveset recovery would look like this..
recover -iY -d "e:\restore" -S 3726371882
with the saveset "ssid" of 3726371882