Re: autolabel and automatic labeling
On Mon, Feb 03, 2014 at 06:47:32PM -0500, Michael Stauffer wrote: > Hi, > > I'm hoping to use autolabel like this: > > autolabel "$b-$c-config-name" > > so that I can do tape labeling like this to easily label new tapes: > > amlabel config-name slot N > > With my definition of autolabel above, will amanda *never* automatically > label a tape that it encounters and is unsure of? This is way I infer from > the autolabel discussion in amanda.conf man page, but it's not stated > explicitly. I'd like to play it safe (at least for now) and always manually > label new tapes. It is explicit on the amlabel manpage: "As a precaution, amlabel will not write a label if the volume already contains an active label or if the label specified is on an active tape. The [-f] (force) flag bypasses these verifications." jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
autolabel and automatic labeling
Hi, I'm hoping to use autolabel like this: autolabel "$b-$c-config-name" so that I can do tape labeling like this to easily label new tapes: amlabel config-name slot N With my definition of autolabel above, will amanda *never* automatically label a tape that it encounters and is unsure of? This is way I infer from the autolabel discussion in amanda.conf man page, but it's not stated explicitly. I'd like to play it safe (at least for now) and always manually label new tapes. Thanks. -M
Re: 'labelstr' param in amanda.conf
Yes, each DLE is handled as a separate dump --- which is why specifying the spindle number is good, if several DLE's are on the same spindle. (However, I never specify the spindle number!) Yes, you definitely want your DLE's in chunks. A chunk of half the size of your tape feels right to me. That way, a big level 0 dump can fit on a tape, and a bunch of smaller DLEs or level 1 dumps can still fit on the tape too. If you are using virtual tapes, then just decide what is a reasonable size for each DLE (regarding having to retry if it fails, etc). On Feb 3, 2014, at 2:44 PM, Michael Stauffer wrote: > Deb, thanks very much for this detailed answer. > > So if I understand correctly, if I follow your advice and have a number of > entries in my config's DLE, and call 'amdump myconfig', each DLE entry is > handled as a separate dump as amdump runs? That is, my main concern is to do > dumps in chunks so that with large full dumps, if there's an error, there's > no single massive dump that gets compromised and must be repeated. Also, > worst-case scenario restoration from smaller dumps will be easier. Does that > sound right? Yes, to all of these! Just don't subdivide so much that it becomes unwieldy. And, you want to make sure you don't miss any new files, so I always have one dump which is /disk (meaning all of it) but with an Tar exclusion file excluding all the areas that I've already separately dumped (such as /disk/A/disk/B ). That way, if somebody creates an area like /disk/Aa or even /disk/123 it DOES get backed up somewhere, on my "AllTheRest" DLE. > When doing incremental dumps with this setup, does amdump combine the changed > files from various entries in the DLE until it reaches the minimum dumpsize I > set to fill a tape? Or is each DLE still handled separately even if none of > them is large enough to fill a tape (or match whatever dump size limit is > set). No it won't combine them, but it will put the small dumps from lots of different DLEs onto the same tape, until the tape gets full. They are still handled separately. Lots of different DLEs go onto the same same wether they are level 0 or incremental backups -- they are just a different *.dmp (and then gzip) file on the tape. The tape gets lots of those, until it is full. Deb > > Also, I like the advice on doing archive dumps, seems straightforward. I'll > be needing to do those too. > > -M > > > On Thu, Jan 16, 2014 at 11:41 PM, Debra S Baddorf wrote: > Since others have diverted into providing answers for your tape type, I'll > resurrect this question and give some sort of an answer. > > Yes, you probably need just one configuration and one group of tapes labelled > per 'labelstr'. You create a list of DLEs to make smaller than tarp sized > chunks. >node /diskname dumpname [spindle Local ] (optional) >node /disk2/aDir tar-type-dumpname [...] >node /disk2/another tar-type-dumpname [...] >node2 /diskname dumpname [spindle Local ] (optional) >node2 /disk2/aDir tar-type-dumpname [...] >node2 /disk2/another tar-type-dumpname [...] > Etc > > Then, optimally, you create a cron job for each night (or maybe only week > nights), something like this: > 21 00 * * * amdump myconfig > And let Amanda shuffle your DLEs into a similarly sized amount each night. > > Stop reading here, for the simplest setup. > > --- > > If perchance the manager of nodeN insists on checking his dumpdates log on > the same day each week, you CAN force nodeN with another cron entry & script: > > "If Wednesday then amadmin myconfig force nodeN * " > Or perhaps only amadmin myconfig force nodeN /usr > > Things like that. It forces Amanda to do a level 0 THAT day, on whatever > DLEs you do it for. It messes up Amanda's balancing, but if you have a lot > of DLEs it'll even out somewhat. > > You also CAN do a force on all DLEs ( * * ) on the day that you want a whole > set of level 0's. But that really messes up the balancing & isn't the best > idea. > > - > > I personally DO run a second configuration (archive) and a second set of > tapes (same tape drive) so that I can get an archive tape. I set it "no > record" so it doesn't change the dumpdates, and so it doesn't stop other > level 0's from being done in the normal configuration . I do a "force" on > all my DLEs and run it once a month. These tapes go offsite, so I want my > daily configuration to have its own set of level 0's. Level 0's at least > once a week (my dumpcycle) but then I keep 5-6 weeks of tapes before I > recycle and start overwriting those level 0's. > > > > Deb > > On Jan 16, 2014, at 5:01 PM, "Michael Stauffer" wrote: > >> Thanks for the reply. I don't have multiple configurations, I'm just trying >> to figure out how to set things up. >> So it sounds like I can have a single configur
Re: 'labelstr' param in amanda.conf
Deb, thanks very much for this detailed answer. So if I understand correctly, if I follow your advice and have a number of entries in my config's DLE, and call 'amdump myconfig', each DLE entry is handled as a separate dump as amdump runs? That is, my main concern is to do dumps in chunks so that with large full dumps, if there's an error, there's no single massive dump that gets compromised and must be repeated. Also, worst-case scenario restoration from smaller dumps will be easier. Does that sound right? When doing incremental dumps with this setup, does amdump combine the changed files from various entries in the DLE until it reaches the minimum dumpsize I set to fill a tape? Or is each DLE still handled separately even if none of them is large enough to fill a tape (or match whatever dump size limit is set). Also, I like the advice on doing archive dumps, seems straightforward. I'll be needing to do those too. -M On Thu, Jan 16, 2014 at 11:41 PM, Debra S Baddorf wrote: > Since others have diverted into providing answers for your tape type, > I'll resurrect this question and give some sort of an answer. > > Yes, you probably need just one configuration and one group of tapes > labelled per 'labelstr'. You create a list of DLEs to make smaller than > tarp sized chunks. >node /diskname dumpname [spindle Local ] (optional) >node /disk2/aDir tar-type-dumpname [...] >node /disk2/another tar-type-dumpname [...] > node2 /diskname dumpname [spindle Local ] (optional) >node2 /disk2/aDir tar-type-dumpname [...] >node2 /disk2/another tar-type-dumpname [...] > Etc > > Then, optimally, you create a cron job for each night (or maybe only > week nights), something like this: > 21 00 * * * amdump myconfig > And let Amanda shuffle your DLEs into a similarly sized amount each night. > > Stop reading here, for the simplest setup. > > --- > > If perchance the manager of nodeN insists on checking his dumpdates log > on the same day each week, you CAN force nodeN with another cron entry & > script: > > "If Wednesday then amadmin myconfig force nodeN * " > Or perhaps only amadmin myconfig force nodeN /usr > > Things like that. It forces Amanda to do a level 0 THAT day, on > whatever DLEs you do it for. It messes up Amanda's balancing, but if you > have a lot of DLEs it'll even out somewhat. > > You also CAN do a force on all DLEs ( * * ) on the day that you want a > whole set of level 0's. But that really messes up the balancing & isn't > the best idea. > > - > > I personally DO run a second configuration (archive) and a second set > of tapes (same tape drive) so that I can get an archive tape. I set it "no > record" so it doesn't change the dumpdates, and so it doesn't stop other > level 0's from being done in the normal configuration . I do a "force" on > all my DLEs and run it once a month. These tapes go offsite, so I want my > daily configuration to have its own set of level 0's. Level 0's at least > once a week (my dumpcycle) but then I keep 5-6 weeks of tapes before I > recycle and start overwriting those level 0's. > > > > Deb > > On Jan 16, 2014, at 5:01 PM, "Michael Stauffer" > wrote: > > Thanks for the reply. I don't have multiple configurations, I'm just > trying to figure out how to set things up. > So it sounds like I can have a single configuration that uses the same > group of tapes as defined by 'labelstr', and I use the DLE lists to break > things up into manageable chunks. Then with amdump, I can specify the > individual DLE's to be dumped? > > -M > > > On Thu, Jan 9, 2014 at 1:58 PM, Jean-Louis Martineau > wrote: > >> On 01/09/2014 01:47 PM, Michael Stauffer wrote: >> >>> >>> Hi, >>> >>> I'm setting up amanda 3.3.4. >>> >>> Regarding 'labelstr' in amanda.conf: >>> >>> The documentation says: "If multiple configurations are run from the >>> same tape server host, it is helpful to set their labels to different >>> strings (for example, "DAILY[0-9][0-9]*" vs. "ARCHIVE[0-9][0-9]*") to avoid >>> overwriting each other's tapes." >>> >>> Does this mean that if I have multiple configurations in order to break >>> up a large 30TB data set into managable chunks, each configuration will >>> have to have a particular set of tapes assigned to it? That seems very >>> awkward if so. >>> >>> >> yes >> >> Why do you have multiple configurations? >> You should do it with one configuration and multiple dle. >> >> Jean-Louis >> > >
Re: amanda and pigz
On 01/29/2014 09:13 AM, Michael Müskens wrote: You can't use amrestore to directly read the dump from a vtape, use something like: amrestore -r file:/backup/tapepools/DailySet/DailySet-69 For that I would have to point the data-link to the needed tape? That is something I actually wanted to avoid :) or : amtape CONF label DailySet-69 amrestore -r file:/backup/tapepools/DailySet It is a lot easier to use amfetchdump: amfetchdump CONF tobak012.intern.backup.muessi.de /etc 20140128003001 That command obviously needs human interaction and has to be run as user backup? Newer version have a '-a' option that do not needs human interaction. backup@tobak012:~/hoehoe$ amfetchdump DailySet tobak012.intern.backup.muessi.de /etc 20140128 1 volume(s) needed for restoration The following volumes are needed: DailySet-69 Press enter when ready I want to avoid that too. So far running amanda-2.6.1 I used to autorestore via amrestore -p tobak012.intern.backup.muessi.de |tar [option] - ./ which is rather fine in running automatically, unattended and with no need of an amanda-Database. As I understand, amrestore so far only has been a wrapper for dd if= bs=32k skip=1? Why has this simple functionality been changed? It is a lot more that a simple dd. No offense, just wondering :) /mm -- BOFH excuse #244: Your cat tried to eat the mouse.
Re: amanda and pigz
On 01/27/2014 01:35 PM, Stefan G. Weichinger wrote: Do I have to use a specific version of amanda (newer than release X) to make use of pigz? I tested 3.3.6 using pigz as a client-compress-custom options and amrestore can restore it. I don't know exactly what's the problem, so I can't tell you when it was fixed. Jean-Louis I use it for compressing on a new client but the amrestore on the server has problems to unpack the stuff: amanda@backup /mnt/md4/restore/verify $ amrestore /dev/nst0 Restoring from tape daily03 starting with file 1. amrestore: 1: restoring split dumpfile: date 20140123220010 host main disk virt-backup-IKW_SQL part 1/UNKNOWN lev 2 comp N program /bin/tar amrestore: 2: restoring split dumpfile: date 20140123220010 host main disk 2013 part 1/UNKNOWN lev 0 comp cust program /bin/tar client_custom_compress /usr/bin/pigz ERROR: /usr/bin/pigz exited with status 2 amanda-3.2.1 on the server (we had to keep it on that version because of several dependencies ... app, glibc, kernel) ... pigz installed long after amanda ... in the correct path. So far I haven't found out what "status 2" means here. I assume I should re-install amanda with "debug" on and read the logs, right? Thanks, Stefan
Re: amanda and pigz
Am 29.01.2014 15:13, schrieb Michael Müskens: > So far running amanda-2.6.1 I used to autorestore via > > amrestore -p tobak012.intern.backup.muessi.de |tar [option] - ./ > > which is rather fine in running automatically, unattended and with no need of > an amanda-Database. > As I understand, amrestore so far only has been a wrapper for dd if= > bs=32k skip=1? > Why has this simple functionality been changed? > > No offense, just wondering :) I just tested this at the customer and we also had to do that dd/tar-piping ... why is amanda able to untar gzip-packed stuff correctly (is it still?) and does not do the same for pigz-packed stuff (which is also gzip-format afaik)? call it a feature request ;-) IMO it should not be necessary to use plain dd etc in case of a restore. As a fallback possibility, yes, but not in the normal use of the backup suite, especially not when in a hurry and/or panic because of some server crash ... opinions welcome, Stefan
