Re: Question about vtape size
Jon LaBadie wrote: How are current users sizing their vtapes and what has been their experience in disk usage? I've divided my ~160GB removable disks into 5 vtapes each. I have a total of 8 DLEs, two of which are >40 GB (after compression) and the rest are no larger than 2 GB. On the days when no "large" DLEs get a level 0, vtape usage is only 4 GB or so, whereas on other days it is, of course >40 GB. So I've set the vtape size to 51 GB. 5x51 > 160, but since most of the slots get filled to <10% of the vtape size, this is no problem. It has generally worked well for past couple of years. Interestingly enough, I'm having my first problem with this approach just this week. Past couple of weeks, the changing of removable disks has been repeatedly delayed/forgotten, hence Amanda is desperately trying to do level 0 of everything. Once the disk got replaced, it started writing new level 0s of the large DLEs to the first slots on the disk, while the previous level 0s were still in the last slots. So the disk filled up. We've forgotten to replace the disks on time before, but this is the first time it has caused such problem. Probably because this time we forgot it really bad, for several weeks in the row. I guess if I would split up these large DLEs into smaller pieces using excludes, the problem wouldn't be as bad. When the disks are changed properly, they get filled to ~67%. -- ... Press any key to continue or any other key to quit.
Re: Question about vtape size
On Thu, Feb 02, 2006 at 04:39:47PM +0100, Paul Bijnens wrote: > Note that when you write a dump to a vtape, and you hit EOT, the > last incomplete part of a dump is not erased, just like a real tape. Yes, this is sub-optimal. > So, many "incomplete" parts on a too small vtapes do take up real > diskspace (and time too!). 2.5.0b2 has the tape_splitsize dumptype option. I've set my config up to check this out tonight.
Re: Question about vtape size
On Thu, Feb 02, 2006 at 10:01:45AM -0500, Jon LaBadie wrote: > How are current users sizing their vtapes and what has > been their experience in disk usage? Here is what I am currently doing: size of vtapes is set to DVD size. I have written a tape-changer with the capability to be set in "offline" mode. All over the week, the changer is set to "offline", thus I circumvent amanda's balancing strategies. Incrementals cummulate in the holding area. Holding area is copied to a USB disk after backup. I have two USB disks for this which I change once a day. Thus, in case of a disaster, I loose at most one day of backups. Copies of holding-areas which are older than 2 weeks are deleted from the USB disk. At friday night, cron forces all DLEs to level 0 and sets the changer to "online". Along with autoflash, I get all the incrementals and a full dump of every DLE on the vtapes. At saturday, with the help of a script, I: 1. burn/verify all this to DVD's, 2. print the labels, 3. empty all vtapes that are already burned _and_ older than 2 weeks This setup has following advantages: 1. 2 weeks of backups are directly available from the vtape area without fiddling with DVDs. 2. Needed disk size is limited to roughly 2 times of the sum of all DLEs, no matter how many vtapes are used. 3. I have at least two copies of everything that is younger than two weeks. (exception is the level0 that was done at saturday morning. They will go to DVD only at the afternoon on the same day). 4. Since every packet of DVDs that I burn at saturday is a full backup of all my DLEs, it is pretty easy to put some of them away for long-time archival. 5. I am involved to the process only once a week. And here is the disadvantage: 1. Number and size of DLEs is limited. Burning 100 DVDs in one afternoon is not very likely to be realistic ;-) 2. I am involved to the process once a week. :-) I think the disadvantages could be resolved with a real tapechanger and some scripting. But a real tapechanger is much too expensive for me, so I prefer to accept the disaadvantages :-)
Re: Question about vtape size
On Thu, 2 Feb 2006, Jon LaBadie wrote:
> In contrast, when I 'played' with vtapes a year or more
> earlier, I just specified a huge size, knowing it would
> "never" be exceeded. However a possibility was that I
> would run the file system out of space if many vtapes
> were pretty full.
Indeed. Either you waste space, or you have the risk of running out of space.
I chose the second approach: my vtapes are on a local disk, and every 3 weeks I
manually copy the most recent vtapes to a removable disk (I have 2 of them).
Problems:
- Both my local disk and the removable disks are too small to hold the full
tapecycle.
- I have to manually delete vtapes on the local disk on a regular base, to
make space if the disk runs out-of-space.
- Amanda doesn't keep track of vtapes older than tapecycle that are still on
the oldest removable disk.
To solve these, I started writing a script that would automatically migrate
tapes to and from external disks, and create new and destroy old vtapes when
needed, but due to limited spare time it's not yet finished...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Question about vtape size
Jon LaBadie wrote: Kind of a "best practice" or "common usage" query. For those of you using vtapes, how have you chosen to specify the size of a single vtape? A while ago, perhaps 1-2 yrs when vtapes were starting to be used more regularly, the comments seemed to be "divide the available space by the number of vtapes". This ensured that the file system would never run out of space but meant that some available space is "wasted". In contrast, when I 'played' with vtapes a year or more earlier, I just specified a huge size, knowing it would "never" be exceeded. However a possibility was that I would run the file system out of space if many vtapes were pretty full. Gene H., as I under stand it, uses a third variation. He wants X number of vtapes and wants them pretty full. To achieve this he adjusts the dumpcycle & runspercycle parameters. How are current users sizing their vtapes and what has been their experience in disk usage? Sometimes there are other constraints on the size of a vtape. E.g. you want them to fit on a DVD, or make a copy of them to a real tape using dd. In that case I use those constraints: the size of a DVD or of the physical tapes). Otherwise, I specify a quite large value, so that even on a day when Amanda needs to schedule a huge DLE, there is still enough space to fit on one single vtape. In the long run, it is the average value of a vtape that is important. Note that when you write a dump to a vtape, and you hit EOT, the last incomplete part of a dump is not erased, just like a real tape. So, many "incomplete" parts on a too small vtapes do take up real diskspace (and time too!). That's why I try avoid that situation. On a vtape this is easy. Maybe that could be fixed by a little shell script that erases those last useless incomplete parts to free diskspace... Hmmm TODO... (: can you tell I'm thinking about using vtapes :) USB-1 can handle about 1 Mbyte/sec, which is already twice as fast as a DDS2-tape; USB-2 is about 6-8 Mbyte/sec in my test env. -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Question about vtape size
On Thursday 02 February 2006 10:01, Jon LaBadie wrote: >Kind of a "best practice" or "common usage" query. > >For those of you using vtapes, how have you chosen >to specify the size of a single vtape? > >A while ago, perhaps 1-2 yrs when vtapes were starting >to be used more regularly, the comments seemed to be >"divide the available space by the number of vtapes". >This ensured that the file system would never run out >of space but meant that some available space is "wasted". > >In contrast, when I 'played' with vtapes a year or more >earlier, I just specified a huge size, knowing it would >"never" be exceeded. However a possibility was that I >would run the file system out of space if many vtapes >were pretty full. > >Gene H., as I under stand it, uses a third variation. >He wants X number of vtapes and wants them pretty full. >To achieve this he adjusts the dumpcycle & runspercycle >parameters. > >How are current users sizing their vtapes and what has >been their experience in disk usage? > > (: can you tell I'm thinking about using vtapes :) Yup. My method is of course not the only way to skin this particular cat, there not being the possibility of offsite storage, but so far its worked well for me. FWIW I also have lowered the var that controls how many days a given incremental level is used to 1, but at the end of the day I believe it had a minimal effect while using tar 1.15-1. How STar would handle that I haven't investigated. Has anyone? -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
