-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Carwyn Edwards Sent: Wednesday, September 15, 2004 2:15 PM To: Development discussions related to Fedora Core Subject: Re: Homedir backup (was Re: "Stateless Linux" project)
<summary>Stuff about identifying which network we are on to see if we want to do backup.</summary>
If I'm away at a conference with my laptop and they have WiFi access
to
the internet, I don't care which network I am on. I still want to back up my home directory though.
I've got concur and say for homedir backup, the obvious solution is allowing the user to enable and disable it easily. I like the idea of a taskbar throbber applet, and I'd like to easily be able to run some sort of command to enable backups, backup now, and disable backups as well. Right-click menu options on the throbber or whatever would be nice too.
Automatically determining the state based on the network is easily solved once the basics are there. I currently have no easy and efficient solution to backup up my home directory on a stateful machine and sync it back, so I'd prefer to see that happen first.
I think the place to tackle this stuff first for both the home directory and system configuration aspects is with regard to choosing files to backup intelligently. Someone pointed out that their rpm folder is monstrous. Mine is too, as are bunches of other folders floating through my home directory and system. Perhaps a simple standardized home directory layout is in order.
For instance: One might have a ~/tmp into which ~/rpm/BUILD and other junk accumulators would be linked. It would have a no-backup policy. Then perhaps a ~/static or some such where one could put their music files, movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree mirrors, or whatever else they might be hauling around that never changes. Such a folder could (and should) have a different (lower priority, server-wins?) sync policy than, for instance ~/Maildir (high priority, last update wins?).
I realize rsync exclude lists can work around more complex layouts, but I think the idea here is to automate and simplify. In addition, I want 2-way sync on at least some part of my home directory. Splitting it up into a few different policies makes automated sync conflict resolution easier.
Anyway, just another $0.02.
monstrous. Mine is too, as are bunches of other folders floating through my home directory and system. Perhaps a simple standardized home directory layout is in order.
There is no such thing as a 'standardized homedir'
For instance: One might have a ~/tmp into which ~/rpm/BUILD and other junk accumulators would be linked. It would have a no-backup policy. Then perhaps a ~/static or some such where one could put their music files, movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree mirrors, or whatever else they might be hauling around that never changes. Such a folder could (and should) have a different (lower priority, server-wins?) sync policy than, for instance ~/Maildir (high priority, last update wins?).
I realize rsync exclude lists can work around more complex layouts, but I think the idea here is to automate and simplify. In addition, I want 2-way sync on at least some part of my home directory. Splitting it up into a few different policies makes automated sync conflict resolution easier.
The exclude and include lists are trivial.
Open nautilus window or gnome file selector box: drag out the folders you do not want to backup.
And we're done.
-sv
Hmm... This could be applied on a (much) smaller case as well (i will use myself as a use case):
On my "big" machine, i have an 80 GB disk - and most of what is used is in my home folder. I also have a laptop, which i can bring with me.
Imagine that there was a small app that came preinstalled with fedora. It could be written i python or whatever - and it had a nice GUI. When activated, it would start when i booted my laptop (or at least when i logged into GNOME) - in the systray, beside the (pretty usless) RHN-applet. It would then try to connect to my "big" pc when i mount the NFS share (i use NFS to share my big pc's /home/kyrre to my laptop - it has the option "user" in fstab, which makes it possible to mount it from the GNOME gui), and if it detected any differences, it would become red or something - telling me to sync. I could then double-click it, and hit "sync" in order to sync the stuff - and it would sync, displaying nice blue GTK progress bars - one for each individual file, and one for total.
Then it would go back to its happy, green/blue state.
And ofcourse, if i right-clicked the aplet, it would display a "sync" thing - effectively doing the sync in the background, but allowed me to foreground it to see the nice progress bars, and background it again, and a "properties" option. There i could decide what should trigger an attempt to connect (and check whats new), (manual, connected to net (with some ways to id WHICH net), when fs XX is mounted etc etc), and which folders should be synced. For me, that would be the "documents" folder - not the download, music etc. So simply display a checkbox-list (something like the one in epiphanies bookmarks - but with the ability to dive recursively into directories).
Just some small vissions. And it would be extremely usefull as well - i am pretty shure that i am not the only person with a similar use case...
Kyrre Ness Sjøbæk
ons, 15.09.2004 kl. 21.08 skrev seth vidal:
monstrous. Mine is too, as are bunches of other folders floating through my home directory and system. Perhaps a simple standardized home directory layout is in order.
There is no such thing as a 'standardized homedir'
For instance: One might have a ~/tmp into which ~/rpm/BUILD and other junk accumulators would be linked. It would have a no-backup policy. Then perhaps a ~/static or some such where one could put their music files, movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree mirrors, or whatever else they might be hauling around that never changes. Such a folder could (and should) have a different (lower priority, server-wins?) sync policy than, for instance ~/Maildir (high priority, last update wins?).
I realize rsync exclude lists can work around more complex layouts, but I think the idea here is to automate and simplify. In addition, I want 2-way sync on at least some part of my home directory. Splitting it up into a few different policies makes automated sync conflict resolution easier.
The exclude and include lists are trivial.
Open nautilus window or gnome file selector box: drag out the folders you do not want to backup.
And we're done.
-sv
On Wed, 2004-09-15 at 14:47 -0400, Erik LaBianca wrote:
I think the place to tackle this stuff first for both the home directory and system configuration aspects is with regard to choosing files to backup intelligently. Someone pointed out that their rpm folder is monstrous. Mine is too, as are bunches of other folders floating through my home directory and system. Perhaps a simple standardized home directory layout is in order.
For instance: One might have a ~/tmp into which ~/rpm/BUILD and other junk accumulators would be linked. It would have a no-backup policy. Then perhaps a ~/static or some such where one could put their music files, movie rips, ~/rpm/SRPMS, random tarball downloads, fedora install tree mirrors, or whatever else they might be hauling around that never changes. Such a folder could (and should) have a different (lower priority, server-wins?) sync policy than, for instance ~/Maildir (high priority, last update wins?).
I don't think this should be policy pushed from RedHat/Fedora. It seems to be much more of an organizational policy. As long as the user interface presents a reasonable interface for exclusions (I'm not sure that there would be an inclusion option...), with the default 'sync all' concept, it should work fine. Having priority on directories would certainly be interesting, though may have to be tackled at the next pass.
It seems to me that rsync makes a great candidate for this purpose, though there are some limitations (unless I'm just not aware of certain command flags): 1 - being in a library would probably be much nicer for this task, rather than spawning a process and trying to parse it's output 2 - Being a seperate process, there isn't the same ability to start/stop/pause from a user interface. 3 - Does not provide easily machine parseable output for a gui to provide status information
There is a librsync project at sourceforge (http://librsync.sf.net) though it is listed as not wire compatible with the v2 rsync protocol. It may be sufficient for this purpose however.
On Wed, 15 Sep 2004 15:13:10 -0400, David Hollis dhollis@davehollis.com wrote:
It seems to me that rsync makes a great candidate for this purpose, though there are some limitations (unless I'm just not aware of certain command flags): 1 - being in a library would probably be much nicer for this task, rather than spawning a process and trying to parse it's output 2 - Being a seperate process, there isn't the same ability to start/stop/pause from a user interface. 3 - Does not provide easily machine parseable output for a gui to provide status information
There is a librsync project at sourceforge (http://librsync.sf.net) though it is listed as not wire compatible with the v2 rsync protocol. It may be sufficient for this purpose however.
cough rdiff-backup cough librsync based cough python based... like all good system-config tools should be :-> http://rdiff-backup.stanford.edu/ or if you dont want the "mirror" aspects and want a little more privacy http://www.nongnu.org/duplicity/
-jef"using unattended rdiff-backup cronjobs via ssh on his lan for personal data, and man oh man is it fun to wipe his rawhide test box and do a fresh install and be able to restore is whole home directory from his rdiff-backup created backed on the other machine on the lan by asking rdiff-backup to simply drop the /home as it was 2 days ago right back into place, if rdiff-backup were in Core I could problably kickstart that sort of process with obnoxious ease."spaleta
Jeff Spaleta wrote:
cough rdiff-backup cough librsync based cough python based... like all good system-config tools should be :-> http://rdiff-backup.stanford.edu/ or if you dont want the "mirror" aspects and want a little more privacy http://www.nongnu.org/duplicity/
-jef"using unattended rdiff-backup cronjobs via ssh on his lan for personal data, and man oh man is it fun to wipe his rawhide test box and do a fresh install and be able to restore is whole home directory from his rdiff-backup created backed on the other machine on the lan by asking rdiff-backup to simply drop the /home as it was 2 days ago right back into place, if rdiff-backup were in Core I could problably kickstart that sort of process with obnoxious ease."spaleta
<AOL> Preach it, brother! :) </AOL>
Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `-------------------------------------------------
------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------
On Wed, 15 Sep 2004 15:31:15 -0400, Jeff Spaleta wrote:
cough rdiff-backup cough librsync based cough python based... like all good system-config tools should be :-> http://rdiff-backup.stanford.edu/ or if you dont want the "mirror" aspects and want a little more privacy http://www.nongnu.org/duplicity/
$ rpm -q rdiff-backup librsync rdiff-backup-0.12.6-0.fdr.1.2 librsync-0.9.6-0.fdr.5.2
... availability of those rpms at fedora.us should make evaluation even easier.
-
David Hollis -
Eli Carter -
Erik LaBianca -
Jef Spaleta -
Kyrre Ness Sjobak -
Michael Schwendt -
seth vidal