i dont know if ditching the build in scheduler is an option for you but i
will give a little idea of a test environment i am running. i am currently
using the built-in scheduler but it isnt sophisticated enough for my needs.
I am having the client initiate the backup with an ssh session. i have
exchanged keys so no password is required and run an ssh -l backuppc
hostname command to do an incremental backup every day with my incremental
levels a 1-32 so that all month is incrementals. i also have a month end
batch that runs that i run a full backup before and after via the script and
that resets the incrementals. I cannot schedule a full backup because my
month end batch jobs are on the last business day, not the last calendar
day.
i am just running this on a small test directory to minimize times during
testing but plan on moving to this system in the next month as it has been
flawless. i never miss a backup and the many levels of incrementals keeps
them pretty efficient and my incemental sized dont steadily grow through the
month.
also, for anyone who doesnt know how to run ssh commands from a windows
machine on a schedule, install cygwin and the ssh client(and server if you
want rsyncd backups) and then you can just build a script and put it in the
standard windows task scheduler.
On Nov 28, 2007 2:13 PM, Carl Wilhelm Soderstrom <[EMAIL PROTECTED]>
wrote:
> On 11/28 09:00 , John Rouillard wrote:
> > To do this, I limit the number of simultaneous backups to 4, and use
> > --bwlimit 100 to limit the sending rsync speed. This gives us a total
> > of 3,276,800 bits/sec approx. It can be a bit higher at tims, but
> > averages out.
>
> I've never had good luck doing more than 2 backups simultaneously; tho if
> the bandwidth is limited enough it might not crush the disk too badly.
> Good
> on you for getting that to work well for your environment. Anything in
> particular you did to get that many concurrent disk-acessing processes to
> not interefere with each other too badly? (I presume you tested it with
> different levels of concurrency.)
>
> > We are seeing gaps in backup coverage, the worst was a system without
> > backups for three days We have had up to 10 systems with at least 1
> > day's backups missed. Since this is bad (TM), I am looking for ideas
> > on solving this problem.
>
> I've seen this happen myself. Usually it's transient enough that I don't
> worry about it too much. If it did become a problem (as apparently it is
> in
> your environment) I'd suggest getting another backup server, and perhaps
> migrating backups of troublesome hosts off to it. That way the
> non-troublesome backups can run without interference. The downside of
> course
> is that the troublesome backups are all concentrated on one server instead
> of spread out over several.
>
> BackupPC scales horizontally far better than vertically.
>
> --
> Carl Soderstrom
> Systems Administrator
> Real-Time Enterprises
> www.real-time.com
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
