Re: Best size for vtapes
Charles Curley writes: > So in theory you could allocate more vtape space that there is room on > the partition. Just make sure you never use more vtape space than you > actually have. In theory. But you are accepting the risk that from time to time all your vtapes will be 100% full and you will not have enough space on your disk. And I don't think there is any provision in Amanda to prevent that. So I prefer to stick with the amount of vtapes equal to the real amount of disk space. > The answer to that is, "that depends". I have tried to have a vtape > size a bit larger than my typical daily backup, and then allow amanda > to use enough extra tapes to cover the largest likely backup. So most > days I use one vtape, 40-90% filled. Some days I use three or four > vtapes. All but the last are almost 100% filled. You can also play > with your split size. I don't think that depends at all unless you have a very deterministic usage patern. When the size of the daily backup is truly random, it becomes a purely mathematical problem: Each day, you are wasting on average 1/2 vtape amount of disk. So you could have vtape being half the size of what you are using, wasting 1/4 of the initial amount, but then you are wasting x blocks overheard for declaring new directories and using more inodes. When do both fucntions cross? Best regards, Olivier --
Re: Best size for vtapes
On Mon, 18 Nov 2019 13:13:00 +0700 Olivier wrote: > I am wondering what is the best size to declare for the lenght of the > vtapes. Too long a vtape could lead to disk space being unused, You may have a misconception here. Vtapes emulate physical tapes, but not in all respects. If you don't fill up a tape, that unused space is gone. But if you don't fill up a vtape, it simply means there is that much space available for other files, such as other vtapes. So in theory you could allocate more vtape space that there is room on the partition. Just make sure you never use more vtape space than you actually have. > but > having too many small vtapes one or two directories created for each > new vtape, and if many vtapes, the main directory containing them > would not fit in a single inode; but the space left unused would be > smaller. > > My understanding is that splitting a backup does not consume more > space, so it is not the backup data that gets bigger, only what is > surrounding it. > > If wee are not considering the overhead of computing the tape > spliting, nor the possible extra I/O, if we only focus on the disk > space, what would be the optimum size for the vtapes? The answer to that is, "that depends". I have tried to have a vtape size a bit larger than my typical daily backup, and then allow amanda to use enough extra tapes to cover the largest likely backup. So most days I use one vtape, 40-90% filled. Some days I use three or four vtapes. All but the last are almost 100% filled. You can also play with your split size. I suggest you do the rough calculations to get your initial setup, then fiddle with it as you gain experience and as amanda settles its calculations down over time. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Best size for vtapes
Hello, I apologize in advance if the question has already been answered or has become obsolete. I am wondering what is the best size to declare for the lenght of the vtapes. Too long a vtape could lead to disk space being unused, but having too many small vtapes one or two directories created for each new vtape, and if many vtapes, the main directory containing them would not fit in a single inode; but the space left unused would be smaller. My understanding is that splitting a backup does not consume more space, so it is not the backup data that gets bigger, only what is surrounding it. If wee are not considering the overhead of computing the tape spliting, nor the possible extra I/O, if we only focus on the disk space, what would be the optimum size for the vtapes? Best regards, Olivier --
Re: rather simple question around dumpcycle
Am 15.11.19 um 20:32 schrieb Jon LaBadie: > I was not thinking of any algorithm. Just a weekend crontab entries like: > > amadmin ... force ... ; amdump ... Yes, I understood that. But that "manual force" always disturbs the schedule built by the amanda algorithm, right? At least that was my observation, the force didn't work out reliably, I assume because of too much data in relation to the media size and number of tapes.
