| 1 |
On Mar 22, 2004, at 4:23 PM, Anthony Valentine wrote: |
| 2 |
|
| 3 |
> I am using Amanda and I find that it works perfectly for me. |
| 4 |
> |
| 5 |
> Your gripes with Amanda are valid, but consider these points: |
| 6 |
> |
| 7 |
> * Amanda being unable to append to a tape is a design feature. Imagine |
| 8 |
> having a weeks worth of backups on one tape and having that tape go |
| 9 |
> bad. Instead of losing one days backup, you lose a week. This has |
| 10 |
> happened to me before (not with Amanda, but homegrown scripts), and let |
| 11 |
> me tell you, it sucks! |
| 12 |
|
| 13 |
That is definitely a concern - my specific environment has no |
| 14 |
requirement for anything more than a backup from a few days ago so |
| 15 |
loosing a few days due to a tape failure won't be a show stopper for |
| 16 |
me. Most of the content I'm backing up is reasonably static so at |
| 17 |
worst I'd be looking at loosing a few days email or changes... since |
| 18 |
nobody is being payed for their time working on this system the costs |
| 19 |
of recreating lost work are nil. This obviously isn't true for most |
| 20 |
server environments. |
| 21 |
|
| 22 |
> |
| 23 |
> * Amanda cannot span a single disklist/filesystem across more than one |
| 24 |
> tape, but it is easy to work around this. You can either split the |
| 25 |
> filesystem up into different directories and add them individually to |
| 26 |
> the disklist, or you can add the filesystem to the disklist more than |
| 27 |
> once, but use filename exclusions to limit what gets backed up for each |
| 28 |
> one. |
| 29 |
|
| 30 |
This is one way around it to be sure. It still offers no guarantee |
| 31 |
that you will get a final backup that will fit on one tape however. |
| 32 |
The only safe way to make sure your entire filesystem will get backed |
| 33 |
up is to make sure that the filesystem is smaller than a tape. A user |
| 34 |
can fill a disk in a way you won't have anticipated and if you gave |
| 35 |
them the space in the first place they would expect it to be backed up. |
| 36 |
|
| 37 |
> * If Amanda is taking that long to backup to tape, you may not have |
| 38 |
> enough holding disk set aside. |
| 39 |
|
| 40 |
I'm talking about actual tape write time. My streamer can't do more |
| 41 |
than 1.5 MB/sec on a 15G tape so you're looking at nearly 3 hours to |
| 42 |
fill a tape no matter how big your holding disk is. I have a number of |
| 43 |
small filesystems and one that's about 14G. The planner always writes |
| 44 |
that one last (which gives the best chance of most filesystems being |
| 45 |
backed up). When/if the first tape fills up (after nearly 3 hours of |
| 46 |
writing) it is going to start over at the beginning of that 14G |
| 47 |
filesystem and spend another 2 1/2 hours or so writing on to tape 2. |
| 48 |
The ability to append to the next tape would cut a 5 hour run down to |
| 49 |
just over 3 hours - quite an improvement. |
| 50 |
|
| 51 |
> * There are a couple of GUI projects going, though I don't know if any |
| 52 |
> of them are production ready. In any case, one of the better things |
| 53 |
> about Amanda is that once it is setup the way you want it, there is |
| 54 |
> very |
| 55 |
> little for a GUI to help you do. I haven't changed my Amanda |
| 56 |
> configuration since it's initial rollout, except for adding or removing |
| 57 |
> disklist entries with only requires editing one file. |
| 58 |
|
| 59 |
I agree - I don't want a GUI for amanda's configuration, just for |
| 60 |
amrecover. Even that isn't really necessary, it's just a 'nice to |
| 61 |
have'. |
| 62 |
|
| 63 |
Bryn |
| 64 |
-- |
| 65 |
~ |
| 66 |
~ |
| 67 |
:wq |
Archives