Comments on questions that are at the very bottom. On Mar 3, 2014, at 1:47 PM, Michael Stauffer <[email protected]> wrote:
> > > 3) I had figured that when restoring, amrestore has to read in a complete > > > dump/tar file before it can extract even a single file. So if I have a > > > single DLE that's ~2TB that fits (with multiple parts) on a single tape, > > > then to restore a single file, amrestore has to read the whole tape. > > > HOWEVER, I'm now testing restoring a single file from a large 2.1TB DLE, > > > and the file has been restored, but the amrecover operation is still > > > running, for quite some time after restoring the file. Why might this be > > > happening? > > Most (all?) current tape formats and drives can fast forward looking > for end of file marks. Amanda knows the position of the file on the > tape and will have to drive go at high speed to that tape file. > > For formats like LTO, which have many tracks on the tape, I think it > is even faster. I "think" a TOC records where (i.e. which track) each > file starts. So it doesn't have to fast forward and back 50 times to > get to the "tenth" file which is on the 51st track. > > Jon, Olivier and Debra - thanks for reading my long post and replying. > > OK this makes sense about searching for eof marks from what I've read. Seems > like it's a good reason to use smaller DLE's. > > > > 3a) Where is the recovered dump file written to by amrecover? I can't see > > > space being used for it on either server or client. Is it streaming and > > > untar'ing in memory, only writing the desired files to disk? > > > The tar file is not written to disk be amrecover. The desired files are > extracted as the tarchive streams. > > Thanks, that makes sense too from what I've seen (or not seen, actually - > i.e. large temporary files). > > > > So assuming all the above is true, it'd be great if amdump could > > > automatically break large DLE's into small DLE's to end up with smaller > > > dump files and faster restore of individual files. Maybe it would happen > > > only for level 0 dumps, so that incremental dumps would still use the same > > > sub-DLE's used by the most recent level 0 dump. > > Sure, great idea. Then all you would need to configure is one DLE > starting at "/". Amanda would break things up into sub-DLEs. > > Nope, sorry amanda asks the backup-admin to do that part of the > config. That's why you get the big bucks ;) > > Good point! A bit of job security there. ;) > > > > Any thoughts on how I can approach this? If amanda can't do it, I thought > > > I > > > might try a script to create DLE's of a desired size based on disk-usage, > > > then run the script everytime I wanted to do a new level 0 dump. That of > > > course would mean telling amanda when I wanted to do level 0's, rather > > > than > > > amanda controlling it. > > Using a scheme like that, when it comes to recovering data, which DLE > was the object in last summer? Remember that when you are asked to > recover some data, you will probably be under time pressure with clients > and bosses looking over your shoulder. That's not the time you want > to fumble around trying to determine which DLE the data is in. > > Yes, I can see the complications. That makes me think of some things: > > 1) what do people do when they need to split a DLE? Just rely on notes/memory > of DLE for restoring from older dumps if needed? Or just search using > something like in question 3) below? I leave the old DLE in my disk list, commented out. Possibly with the date when it was removed. This helps me to remember that I need to UNcomment it before trying to restore using it. I.E. The DLE needs to be recreated (needs to be in your disklist file) when you run amrecover, in order for it to be a valid choice. So if you are looking at an older tape, you need to have those older DLEs still in place. As I understand it, anyway! > > 2) What happens if you split or otherwise modify a DLE during a cycle when > normally the DLE would be getting an incremental dump? Will amanda do a new > level 0 dump for it? Yes. It's now a totally new DLE as far as amanda knows, so it gets a level 0 dump on the first backup. I've found "amdump myconfig --no-taper node-name [DLE-name] " useful sometimes. It will do a backup of just the requested node and DLE but won't waste a tape on this small bit of data. The data stays on my holding disk. The next amdump will autoflush it to tape with everything else (assuming "autoflush" is set to AUTO or YES -- see your amanda.conf file) I use the --no-taper when I need to test a new DLE to make sure it works, before the regular backup is due. Or perhaps, to get that new level-0 out of the way now, so it doesn't extend the runtime of the regular amdump job. > > 3) Is there a tool for seaching for a path or filename across all dump > indecies? Or do I just grep through all the index files in > /etc/amanda/config-name/<index>/ ? Dunno. Somebody else answer? I would just grep, or look in my disklist file, since I try not to completely remove any DLEs. Deb Baddorf > > Thanks > > -M
