I'll start with my usual 'we mostly do stuff in csh here' disclaimer. :-)
That said, my solution would be:
1) send list of paths to file (using /tmp/FILE here)
2) recover -d destination -S ssid[/cloneid] `cat /tmp/FILE`
Alternate method (the way we'd actually do it in a script):
1) [same as above]
1a) set L_REC_PATHS = `cat /tmp/FILE`
2) recover -d destination -S ssid[/cloneid] $L_REC_PATHS
In solaris csh, the only limit (when built this way) seems to be the total
number of arguments (approx 1000). I'm not sure if this was fixed in Linux
tcsh or if this problem even exists in sh/bash, as I've not done any major work
in those.
We don't hit this 'bug' in csh very often; I think there are two distinct cases
we watch for currently. But for your original 'over 1000 paths' case, I'd
consider filing an RFE to allow -I on a SaveSet Recover.
--TSK
-----=====
Tim Kimball
http://sungak.net
-----Original Message-----
From: George Sinclair [mailto:george.sinclair AT NOAA DOT GOV]
Sent: Wednesday, March 14, 2012 2:45 PM
Subject: Re: How to recover multiple paths?
On 2012-03-14 02:06, bingo wrote:
> The only way i see is the possibility to run a partial save set recover
> (recover -d destination -S ssid[/cloneid] -a full_pathname).
> Be aware that you need to be precise about the exact path name. It just
> compares the string you provide with the pathnames read.
>
> I never used it without the -a option.
> I never tried whether this command accepts multiple path names.
> I also did not pay attention whether this will speed up the recovery
> (can/will NW not start reading from the beginning of the save set?)
My experience is that it always starts at the beginning of the save set
and reads all the way through to the end, even after the affected paths
have been restored. Of course, you could cancel the recover operation
once the desired files have been recovered, but you might not be around
at the time when that happens. And looping the recover command through
each desired path would be a waste of time on such a large save set
since it would start over each time and read all the way through for
each path. The '-a' option checks the index without putting you in
interactive mode. This won't help on a save set recover for a save set
that is no longer browsable. I don't see how one would specify a large
number of paths on the command line or even if the recover command would
be able to handle that many or what the threshold is. It might be
shell/OS dependent? It seems unfortunate that the '-I' option for an
input file is only supported for entries still in the index when used in
conjunction with the '-a' option.
In my case, I simply specified all the paths on the command line, and
there were 29 of them (like /dir1/dir2/blah-blah-blah/fname.txt). Rather
then typing all of them, I just used something like 'cat
/tmp/list_of_paths | awk '{ORS=""; print " " $1}' and then pasted that
result to the end of the recover command ('recover -s server -S
ssid/cloneid -d relocation_dir'). That was a lot of characters, but it
took it and recovered them happily nearly 8 hours into the read
operation. But there was no way I was going to recover the entire save
set, but this got me thinking what if I had a lot more paths than 29?
Maybe I'd have to figure out what the max number of paths I could pass
to the command and then loop it for each set of those?
George
> Besides that you may of course use multiple command/terminal windows to run
> multiple processes simultaneously.
Yes, that's a good idea that I often forget about. Now, if I could
figure out what the maximum number of paths (total characters) I could
pass to the recover command (maybe based on the limitations of the shell
and/or the recover command itself?) then maybe I could run that command
in one window and another one in another window, picking up with the
next set of path names, so just divide the job up into multiple windows,
each specifying the maximum number of paths that the command/shell will
accept. Might take a number of windows if you had a lot of files, though.
Another possibility that occurred to me later would be to simply recover
the entire save set (no named paths) but have some parallel running
shell script process that deletes any recovered files unless they match
the desired path names you have specified in some file. Then it sleeps
for a minute and then re-checks or some such thing. Then specifying the
desired paths on the command line would be moot, and you could list them
in the input file instead.
George
> +----------------------------------------------------------------------
> |This was sent by carsten_reinfeld AT avus-cr DOT de via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
