>>>>> On Fri, 15 Aug 2008 23:32:17 +0200, Kern Sibbald said: > > On Friday 15 August 2008 23:12:51 Martin Simmons wrote: > > >>>>> On Fri, 15 Aug 2008 18:06:31 +0200, Kern Sibbald said: > > > > > > On Friday 15 August 2008 14:00:12 Kjetil Torgrim Homme wrote: > > > > I needed to restore a subset of some old backups. Restoring the full > > > > backups would need a terabyte of temporary storage, which seemed a bit > > > > wasteful (and inconvenient to get hold of) since the data I was > > > > interested in took less than a gigabyte. > > > > > > > > Anyway -- I implemented a simple regex to filter the files to restore. > > > > It works like this: > > > > > > > > Building directory tree for JobId(s) 28644 ... > > > > There were no files inserted into the tree, so file selection > > > > is not possible.Most likely your retention policy pruned the files > > > > > > > > Do you want to restore all the files? (yes|no): no > > > > > > > > Regexp matching files to restore? (empty to abort): ^/var/log > > > > > > > > The patch adds a new keyword to the bootstrap file, FilePattern, which > > > > the storage daemon will apply to all files before deciding whether to > > > > send the file over to the fd. The fd doesn't need any changes, btw. > > > > > > > > This is just a quick hack, and there is some polishing left to do: > > > > > > The code looks pretty clean and in the spirit of the current code ... :-) > > > > IMHO, the read_records function is the very worst place to decode the > > records looking for regexps, because it breaks the abstraction boundaries. > > Wouldn't it be much cleaner if only the Director and FD needed to know > > about the contents of the records? > > Yes, it would be cleaner, but I don't see how you can do it any other way. > In > any case, the bsr code already knows about Job Type, JobId, Job names, and > Job Levels, so it isn't too much of an extension to make it know about File > names -- though, in this case, the matching is done in the read_record > subroutine rather than match_bsr. > > > > > How about adding a markregex operation to the existing tree building phase > > in the Director (c.f. markdir)? I know this was an old backup, so probably > > pruned from the catalog, but that is a different problem from the one of > > selecting files by regex. > > When the File records are pruned from the catalog, there is no way to get to > the filenames, so there is no tree to be built. At the point this code kicks > in the filenames exist only on the Volume. The only other way to do this > would be for the SD to send all the records to the FD and the FD decides > which ones to restore. However, that is extremely inefficient if a user > wants one file from a 10GB backup that has been pruned.
True, but the whole 10GB has to be read off backup medium anyway, so sending it to the FD might not be a problem. If this kind of restore happens often, then you clearly have the wrong file retention periods :-) > If you have some > other way to add the feature, I would like to hear about it. I would probably use bextract for this, which already contains a partial FD supporting wildcards. I think the "partial" status of this FD (and bscan and bls) is the main reason why I didn't like the idea of making yet another partial FD in the SD. __Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
