Hi, Mark, I went back and read your Jan. 16th posting. Sounds like a very ambitious piece of code... Some issues:
-- Because the --include option of rsync (or the include option of an rsync module) is not exclusive, like $Conf{BackupFilesOnly} is, we'd have to work with --exclude (as you said), listing everything we didn't want for each set for a share, make each of those a separate module, and write them to rsyncd.conf. This doesn't need to happen from BackupPC (although it would be nice). It can run perhaps as a cron job on the client, or with DumpPreUserCmd. -- Maybe a simplified one would do as a proof of concept. I'm thinking it would be easier to only balance number of files, not taking into account sizes, memory availability on server and client, etc. And it would run in two passes, one to list and chunk directories in sets, and a second one to consolidate subtrees. It seems doable, but certainly not trivial. Assuming we have that rsyncd.conf nicely constructed, we'd then have to find out the list of modules that applies to the share to be backed up. Something like rsync <host>:: would return, say, shareA_set1 shareA_set2 shareB_set1 shareB_set2 and then it would have to be filtered for the relevant modules (assuming they are named sensibly). This could be done at DumpPreUserCmd too. So let's say we are backing up share B: the relevant modules are shareB_set1 and shareB_set2. Next, we need to call rsync with that filtered list of modules. Could it be something like this?: $Conf{XferMethod} = 'rsyncd'; $Conf{DumpPreUserCmd} = <magical command that constructs rsync.conf, and sets a variable>; $Conf{RsyncShareName} = ['shareB_set1', 'shareB_set2']; In particular, I don't know how BackupPC connects to an rsync daemon on the client (I assume it doesn't use the $Conf{RsyncClientCmd} because the comments there say "This setting only matters if $Conf{XferMethod} = 'rsync'"). And can the DumpPre... set a config variable, i.e., $Conf{RsyncShareName};? Or would something like this work, which should be executed when the config file is read? I'm assuming BackupPC rereads/require's the per-pc config file before every dump: $Conf{XferMethod} = 'rsyncd'; $Conf{DumpPreUserCmd} = <regular command not related to rsyncd>; sub get_modules { my($host, $share) = @_; [...] # Magic happens here, and @modules is defined. # This sub could conceivably also construct the rsync.conf on the client. return @modules; } $Conf{RsyncShareName} = [ get_modules($host, $share) ]; And one more question: after all this, is each module backed up independently or are all used at once? The concern here, after all, is memory. If each module was done independently (whether in one or multiple connections) then we'd be limiting memory usage, but if not, we are back where we were... Too many questions, sorry; enough for today. Bernardo [EMAIL PROTECTED] Sent by: To: [EMAIL PROTECTED] [EMAIL PROTECTED] cc: backuppc-users@lists.sourceforge.net ceforge.net bcc: Subject: Re: [BackupPC-users] New user, few questions 01/25/2006 10:51 AM Please respond to backuppc In the message dated: Tue, 24 Jan 2006 19:16:26 EST, The pithy ruminations from [EMAIL PROTECTED] on <Re: [BackupPC-users] New user, few questions> were: => => Dan, => => => > Alternately, just break your backup set into two (or more) pieces. => => Ah, I haven't tried that yet... There are a couple of reasons why: => => -- even though I'm backing up only one machine, I have one "client" per => backed up dir ("share"?, I'm using rsync), because I want to invoke the => creation of a single LVM snapshot at a time with $Conf{DumpPreUserCmd} (I => don't want more than one snapshot simultaneously on the client, at least => for now, for performance and space reasons). => => -- subdirectories below each backed up dir can change, so I can't use a => static list, lest I be forced to maintain it (I'm lazy, I know). => => But now you got me thinking... there might be ways to do it. For example, I => know that in the home partition there is one user that takes as much space => as everybody else together. So that would be a good candidate to break that => backup set into two nearly-equal-size pieces. => This sounds a great deal like what I proposed on Jan 16, describing a suggestion to enhance backuppc to dynamically create backup sets of small sizes. I saw much the same problems as you, with long back times, and the burden of maintaining different backup sets in the face of changing disk usage. Check the archive for the post entitled "rsync dynamic backup set partitioning enhancement proposal". => This is what I have currently: => => $Conf{RsyncShareName} = '/home_snapshot'; => => Would something like this work?: => => $Conf{RsyncShareName} = '/home_snapshot'; => => $Conf{BackupFilesOnly} = { => '/home_snapshot' => [ '/<large_user_home_dir>' ], => '/home_snapshot' => [ some grep-like operation that lists all home => directories, but excludes /<large_user_home_dir> ], => }; => => => Because the config files are Perl scripts, the second list can be generated => dynamically. I'd have to ssh to the client, ls /home_snapshot, filter => <large_user...> out from that directory listing... looks doable... Argh! Exactly. I think this should be built into backuppc... => that wouldn't fly, because two hash entries with the same key means the => second one would overwrite the first one. Hmm, but something along those Not a problem, if you consider the "hash" to be the full path. => lines... Is it possible to have arrays of arrays?: Yes, perl conceptually supports arrays of arrays. I don't know if that would work w/in backuppc as it is now. => => $Conf{BackupFilesOnly} = { => '/home_snapshot' => [ => [ '/<large_user_home_dir>' ], => [ some grep-like operation that lists all home => directories, but excludes /<large_user_home_dir> ] => ], => }; => => => In which case I could just as well do this: => => $Conf{RsyncShareName} = [ => [ '/home_snapshot/<large_user_home_dir>' ], => [ /home_snapshot prefixed to each element of the filtered list of => home dirs ] => ]; => => => => I bet there is some much simpler way of doing this, and I just have the => blinders on. Yes. Use the "exclude" options in the client-side rsyncd.conf. For example, my backuppc server connects to a number of targets (in rsync terminology, a "module") on the clients. The clients then define what directories are included/ excluded in each target. In theory, the rsyncd.conf file could be build dynamically. Here's a snippet of an rsyncd.conf on a backup client: [justroot] path = / exclude = boot cdrom home opt tmp usr usr/local var win98 proc sys mnt/*/* [usr] path = /usr exclude = usr/local/ [usr_local] path = /usr/local The backuppc server simply connects to the client modules "justroot", "usr", "usr_local", and so on, without maintaining the exclude lists on the server. Each of these targets, corresponding to mount points, could easily be generated dynamically. => => => > cat5e should work fine for gigabit (it is the specified cable for => > 1000baseT). You don't need cat6. => => Thanks for correcting me on cat 5e vs cat6. That's good news for me. => => => Bernardo Rechea => Mark ---- Mark Bergman [EMAIL PROTECTED] Seeking a Unix/Linux sysadmin position local to Philadelphia or via telecommuting http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/