Dazed_75 wrote: > On 11/22/06, *Eric Shubes* > 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' --------------------------------------------------- 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