sbackup - looking for info

[Eric "Shubes"]

Dazed_75 wrote:
> On 11/22/06, *Eric Shubes* <plug at shubes.net <mailto:plug at 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

Sure, let's go with the flow. I think using sbackup is fine. I just haven't
seen/used it yet (I've seen/used many others).

>     .) 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.

I can understand that. Writing to optical media is not quite the same as
writing to a HD.

>     .) 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.
> 
Would it be simple enough to just use k3b to burn the backup
directory/files? I don't know, but perhaps there's a way to feed a macro to
k3b so it burns the backup without having to do much of anything.


-- 
-Eric 'shubes'