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
|
