Re: GBackup
- From: Nathan Clemons <nathan windsofstorm net>
- To: Ed Warnicke <hagbard physics rutgers edu>
- cc: gnome-list gnome org
- Subject: Re: GBackup
- Date: Tue, 29 Jun 1999 23:13:37 -0500 (EST)
My current backup status is pending some more SLR 4 tapes, but my plan is
to actually use tar in combination with find to actually put the data to
the drive. For GBackup, I'd recommend that there be two settings: server
backup and backup solution. Backup solution would work with something like
Amanda to handle backing up an entire network. Amanda has been around a
long time, and frankly, it doesn't make sense (IMNSHO) to start from
ground level when they have something so fully featured.
On the other hand, as I discovered, Amanda is horrific overkill for a
single-server backup. For this type of system, doing a simple script is
much better.
However, with my current projects, I have little time to actually work on
this other than conceptually. I'm going to bounce this over to the
gnome-list and see what they think; perhaps we can get the ball rolling
and let freer hands manage it.
-------------------------------------------------------------------------
Nathan P. Clemons "Peace favor your code."
nathan@windsofstorm.net ICQ: 2810688
IN CONSTRUCTION: http://gnome.windsofstorm.net
-------------------------------------------------------------------------
On Tue, 29 Jun 1999, Ed Warnicke wrote:
> I'm curious what you have in mind.
> I currently have some rather evil backup needs of my own which are
> being held together with bubble gum so to speak. I've got
> about 70Gig of data spread across harddrives on about
> 80 machines being backed up to DLT drives on 5 seperate machines
> each night.
>
> And the worst part is, I've inherited the system from someone else.
> So how exactly does one add a volume to be backed up to such a
> system? Simply partitioning volumes into batches to go
> out to the DLT's is a chore.
>
> For this reason I suggest the following:
>
> 1) Such a system should be able to take a list of fs's to be backed
> up and divide them into batches of a size appropriate to fit on
> whatever size the backup device is.
>
> 2) The program should be able to backup across the network,
> handling both fs's to be backed up and backup devices
> on machines other than the one on which to program is
> run.
>
> 3) GUI status display: The best way to deal with this
> problem is to seperate your actual backup program
> from the gui that interacts with it. I see no reason why
> I shouldn't be able to launch the gui interface and
> peak in on a backup in progress, then kill the tool and
> have the backup progress. This simply requires the
> backup program to be able to message the gui tool.
> Should be cleanly doable.
>
> Just some thoughts from someone in backup hell.
>
> Ed
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]