Am Die, 2003-06-24 um 18.05 schrieb Jon LaBadie: > On Tue, Jun 24, 2003 at 05:32:50PM +0200, Heinz-Josef Claes wrote: > > > > There will be some time until the guys here have a testing environment > > and can test it. It's really good news that it seems to be possible > > without big problems. > > If you have some time you might consider the following. > > Amanda uses a non-traditional algorithm for scheduling backups. > That is a major function of amanda, doing the scheduling. > Traditional schemes call for an "all one day", "partials the others". > Local practice might also call for keeping one or more of those > "all one day" backup sets off-site. > > Amanda can be coerced into this model, but it is not comfortable. > Instead, amanda spreads the level 0 backups of entities known as > "disklist entries" (DLE's) which are file systems or directory > trees of a specific client host. So on each dump run, amanda > will do a mix of level 0's of some DLE's and incrementals of > the rest. The amanda administrator specifies how often > the level 0's get done (the dumpcycle parameter), but not when. > > A major advantage to some is a consistant day-to-day tape usage > and time to backup rather than huge requirements one day and > tiny requirements the others. > > Off-site storage would then require either a separate amanda > configuration to do a complete dump of everything in one shot, > or alternatively, storing a "dumpcycle's" collection of tapes. > > > Another thing you might consider doing before the test environment > is fully available, is setting up an amanda configuration on one > or three linux clients that backup to disk instead of tape. This > is possible with recent versions of amanda using what is called > the "file:driver". The setup of amanda going to tape is 90+ pct > the same as backing up to disk. The practice before the pressure > of the real thing could be valuable.
I plan to have a backup in several stages. Now: The data is on file and print servers in different buildings. The network is not fast enough to make a full backup over it. So today (on NT), incremental backups are made to a central point to these IBM robots, and full backup on tapes connected directly to the file and print servers. About three people are jogging through the city to collect the tapes and to repair tape drives. Future: When the file and print servers are converted to linux (where support to the existing backup tool seems to be poor), I plan the following scenario: The data from the file and print servers is synchronised in the night via rsyc to some cheap servers with fat disk (IDE raid). (No tape drive will be connected any more to the file and print servers.) From these "fat" servers there will be two backups: 1. A backup with storeBackup to another server with fat disks. This provides a snapshot like backup for the past with very efficent space management. If somebody wants to restore old files or directories, it's possible directly from a hard disk which is very fast and easy. (It can also be used by a user without additional trainig.) (storeBackup can be found via freshmeat.net) 2. A backup to tape (with amanda) which will only be used, if one of the cheap machines breaks totally. These tapes are mainly for the safe. Perhaps it is enough to make a backup once or twice a week, there is no decision up to know about this. -> So, amanda has a lot of time to do the backup, there are only a few clients (with big storage) to the servers (with the robots) and perhaps we can use less robots because we will not do a daily backup. Regards, Heinz-Josef Claes
