On 11/22/06, Eric Shubes <
plug@shubes.net> wrote:
>
> 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.
True, except that it seems to be semi-automatic with sbackup. The default
scheme seems to be a full backup of some periodicity with incrementals
between. The user does nothing differently. The user can, of course,
change the scheme or do extra work to do things differently. The second
time I ran it, I simply started it, clicked on the backup now button and
what I got was an incremental backup. BTW, one can also set scheduled
backups. I had just not done so. They would also use whatever backup
scheme had been set. I also think I read that restore method automatically
dealt with the full/incremental combination although I would not swear to
that so need to check again.
KISS is a great principle but in this case it could mean going with the
flow. OTOH, my suggested ideal for the copy to CD script was definitely not
KISS oriented
.) How often do you expect that users will actually run their backup? The
> less frequent, the less benefit of incrementals.
Any backup is better than what most people do. sbackup just seems to make
it pretty easy to do whatever frequency you want. The only problem being
what I stated earlier. The default backup is to /var/backup/ on the local HD
unless the user selects a different destination. CD/DVD is not an option
yet supported by sbackup and network destinations are not viable for too
many people.
.) 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.
True. But that would be more a choice of backup scheming than how to get
the backups to CD/DVD. As I said in the scripting description, that was an
ideal and once scripted the user has no involvement and the script would
still work for whatever scheme was in place.
.) 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.
This could be a big issue for people that put a lot of pictures, music, or
other variable data that might eat CDs rapidly. They would be better served
using some kind of network attached storage I suspect.
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.
As stated, the default is for all backups to go to /var/backup/
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.
This is what I did not know how to do. I looked at the man page for
cdrecord and found it unhelpful. I had not thought to make an iso since I
had a focus on the multisession aspect so as not to be producing tons of
CDs. I truly like the idea of having a single media containing a full and
all the incrementals done until another full backup is done. However, your
point about doing only full backups is well taken even though some folks
would take that as only doing a backup every month or three.
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
>
--
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
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
![M](../imgs/g.png "Eric \\"Shubes\\" at 2006-11-22 13:58")
(text/plain)