Thoughts:
.) Incremental backups might be overkill and overly complicated for a lot of
folks. KISS. W/out incrementals, restoring and burning are both simpler
processes.
.) How often do you expect that users will actually run their backup? The
less frequent, the less benefit of incrementals.
.) CDs are inexpensive (FreeAfterRebate when you can find them). Much better
to have multiple full backups in case there's a problem with a given CD.
.) One challenge I see is if data is >700M. Might want to use DVD in that
case. Otherwise, need a way to chunk it up. I don't think there's a way to
span CDs. Great if there is one though.
As a KISS start, you could use sbackup however you like. To do the burn,
it'd be convenient if the backed up data was exclusively in a single
directory. Then you simply need a script essentially does the mkisofs
(create a temp iso image file) and cdrecord (burn the iso) commands. The
script will probably need a few other setup/cleanup kinds of things, but
it'd be rather simple.
Dazed_75 wrote:
> sbackup already contains the means to define what to save. It even has
> the means to save over the network for folks who have one and can set up
> the shared disk access (including security). The only missing part is
> writing to a CD. The sbackup site shows that has been a future project
> for some time.
>
> Meaning the project is essentially reduced to scripting a means to write
> the backups to a CD. Ideally in a multisession mode so the incremental
> backups are added to the existing CD. IOW, sbackup could be set up to
> do regular backups as a full backup followed by incrementals. The
> destination would be local hard disk for some folks but could be NAS or
> shared disk somewhere. The user would periodically put in a CD. If the
> CD was blank, the full backup and all subsequent incrementals would be
> copied to the CD as a session. If the CD already contained backups, the
> script would write any additional incrementals to another session on the
> CD.
>
> One thing I do not know about that scheme is whether the multisession CD
> could be used for a restore to a new drive after installing an OS and
> sbackup. IOW, I do not understand any ramifications of a multisession
> CD which had never been "finalized" if that is a meaningful question.
>
> Hopefully that clears up the question a bit. sbackup actually looks
> fairly complete exceot for that piece although much of that opinion is
> based solely on reading rather than experience.
>
> On 11/21/06, *Eric Shubes* <plug@shubes.net <mailto:plug@shubes.net>> wrote:
>
> First off, I'm not familiar with sbackup.
>
> That being said, I think this could be a nice project to do for the
> computer
> clubs. It'd be fairly easy (again, I think) to write a script to do what
> you'd really like to do (once you decide what that is, which is part
> of the
> project).
>
> To make things easy, I'm thinking of a process which would take
> (read from a
> configuration file) a list of directories where user 'stuff' is located
> (/home and whatever else) and burn a normal CD of all the stuff.
> This would
> not be difficult. Then the files would be accessible in a fashion
> that most
> users are familiar with.
>
> That's the simple version. Variations to the process could be added as
> enhancements.
>
> What say you?
>
> Dazed_75 wrote:
> > I was asked to look into sbackup (from the Google summer of code 2005)
> > as a backup tool. I have installed it on ubuntu 6.10 from the default
> > repositories. The intent was related to individual users in the
> various
> > computer clubs. Some of these folks have single computers while
> others
> > have small networks of systems.
> >
> > On first look, I thought it not appropriate for most individuals since
> > it could not write to CD/DVD yet and other means were mostly network
> > based. In addition, the backup are owned by and only accessible
> to root
> > (see bottom of message). Even though this is proper considering the
> > default inclusions for the backup, it might be a hardship and/or
> > confusion for a typical user.
> >
> > I raise 2 questions:
> > 1 - Does anyone have experience(s) or opinions with sbackup they
> can share?
> > 2 - How could one best write these root owned files to a CD (Note:
> > multisession would be ideal so the incremental backups can just be
> added
> > as they occur)?
> >
> > FYI, this is a listing showing the directories and files resulting
> from
> > 2 backups (notice the second seems to indicate being incremental):
> >
> > root@lapdog1:~# ls -alF /var/backup
> > total 16
> > drwx------ 4 root root 4096 2006-11-20 16:33 ./
> > drwxr-xr-x 16 root root 4096 2006-11-14 21:27 ../
> > drwx------ 2 root root 4096 2006-11-14 21:28
> > 2006-11-14_21.27.23.273683.lapdog1.ful/
> > drwx------ 2 root root 4096 2006-11-20 16:34
> > 2006-11-20_16.33.31.784390.lapdog1.inc/
> > root@lapdog1:~# ls -alF
> > /var/backup/2006-11-14_21.27.23.273683.lapdog1.ful/
> > total 32300
> > drwx------ 2 root root 4096 2006-11-14 21:28 ./
> > drwx------ 4 root root 4096 2006-11-20 16:33 ../
> > -rw------- 1 root root 218 2006-11-14 21:27 excludes
> > -rw------- 1 root root 32152144 2006-11-14 21:28 files.tgz
> > -rw------- 1 root root 539775 2006-11-14 21:27 flist
> > -rw------- 1 root root 279222 2006-11-14 21:27 fprops
> > -rw------- 1 root root 36344 2006-11-14 21:28 packages
> > -rw------- 1 root root 4 2006-11-14 21:28 ver
> > root@lapdog1:~# ls -alF
> > /var/backup/2006-11-20_16.33.31.784390.lapdog1.inc/
> > total 4656
> > drwx------ 2 root root 4096 2006-11-20 16:34 ./
> > drwx------ 4 root root 4096 2006-11-20 16:33 ../
> > -rw------- 1 root root 39 2006-11-20 16:34 base
> > -rw------- 1 root root 218 2006-11-20 16:33 excludes
> > -rw------- 1 root root 4613109 2006-11-20 16:34 files.tgz
> > -rw------- 1 root root 46465 2006-11-20 16:34 flist
> > -rw------- 1 root root 29318 2006-11-20 16:34 fprops
> > -rw------- 1 root root 36344 2006-11-20 16:34 packages
> > -rw------- 1 root root 4 2006-11-20 16:33 ver
> >
> >
> > --
> > Be who you are and say what you feel, because those who mind don't
> > matter and those who matter don't mind. - Dr. Seuss
> >
> >
> >
> ------------------------------------------------------------------------
>
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> <mailto:PLUG-discuss@lists.plug.phoenix.az.us>
> > To subscribe, unsubscribe, or to change you mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
--
-Eric 'shubes'
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)