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