On Monday 14 October 2002 03:36, Toralf Lund wrote: >> On Fri, Oct 11, 2002 at 09:15:34AM +0200, Toralf Lund wrote: >> > >On Thu, Oct 10, 2002 at 01:38:18PM +0200, Toralf Lund wrote: >> > >> Forgot to mention this earlier: I'm not using incrementals >> > >> at all. >> > > >> > >Tapes >> > > >> > >> from the same week will contain full backups of different >> >> directories, >> >> > >and >> > > >> > >> a given file is backed up (only) once a week. >> > > >> > >OK, I'll bite... How hard did you have to twist amanda's arm >> > > to >> >> convince >> >> > >her to do that? >> > >> > dumpcycle 1 week >> > .... >> > skip-incr >> >> Tofalf's scheme raises a question in my mind about how does >> amanda handle this scheme. Maybe someone else has experience >> with something similar. >> >> Suppose I have lots of disklist entries. >> Further, suppose I use >> >> dumpcycle 7 days >> runspercycle 7 >> skip-incr >> >> Will amanda still try for balancing of the nightly dumpsize, >> simply ignoring the incrementals? Seems like it should. >> Anyone doing it? If so, Toralf's scheme, given his requirements >> may be quite reasonable. >> >> >> One thing Toralf; in other postings you mention backing up >> "files". And how it would be difficult to break things up to fit >> into tape size chunks. > >Did I? Must have been a slip... > >All I wanted to say was that incrementals might easily grow very > large because the files are large, so I think I would need a lot > of extra tape to get useful data. (And adding capacity would not > be worth the cost, since loosing the data isn't *that* critical.) > >But I might be wrong, or I could have incrementals for some of the >directories where files are small and/or don't change very often, > but I also thought that it would be a good idea to get the fulls > right first, then start thinking about incrementals, but perhaps > not... > >Anyhow, the original point was that I'm not running incrementals > right now, so archival dumps would be exactly like the normal > ones. > >> Be aware that amanda backs up "disklist entries", >> either file systems or directory trees. You don't tell it to >> backup a system and it picks and chooses which files to backup >> today. It picks and chooses which disklist entries to backup. >> Thus you still have to be concerned with your disklist entries >> fitting on a single tape. > >Yes, I know. I think some way to split the entries across tapes > would be *really* helpful, though.
With tar, and some sort of a guarantee that no individual file will exceed the tape capacity, this can be done by breaking the disklist entries up into subdirs, or in really strange cases, right down to the individual filenames. But if there is no guarantee, given that scenario, that the file will never exceed the tapes capacity, then at some point it will fail, and you should look at some other agent to do the backups for you. The two other choices are bru, bring small wagon load of money, its commercial, or arkeia which requires a larger wagon load of money if you are either commercail, or using a tape library (robot tape changer) but for single drive private useage is free. I have some experience with both but have no idea if either of them can span across to the next tape with one single file. Even thinking about the potential disaster points of doing that gives me the shivers. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.18% setiathome rank, not too shabby for a WV hillbilly
