i guess i have never seen these kinda of numbers for the transfers! what
kind of hardware is being used? is this some old p3 500mhz or something? i
only have experience with backuppc on much more modern hardware. my current
setup is a dual core opteron 2ghz with 2 Gb ram and 4 sata drives in raid5.
i also ran on a a64 1.8ghz single core with 1gb ram an a single drive for
backuppc storage and still did not have these numbers! are these transfers
over a network? if so is that a 100speed network and are you using a descent
peice of hardware or just some netgear switch? i currently run on 100speed
for most of my network but have a couple machines on gigabit with intel
pro1000 cards. if you have a 10 speed network then the math says that a
200GB transfer would take about 91 hours aka 3.8 days(at 50% tcp/ip
efficiency, which is pretty accurate, maybe get 60%). check your network
speed if that is how you do it.
as a side note, i am testing backuppc on an opensolaris box(nexenta alpha)
with zfs and im really liking it! for those who do not know, nexenta is
basically ubuntu 7.04 with an opensolaris kernel instead of linux. i am not
using compress for backuppc because im doing it on the filesystem level and
using zraid which is zfs' version of a load balanced raid5.
On 10/10/07, Carl Wilhelm Soderstrom <[EMAIL PROTECTED]> wrote:
>
> > On 10/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Hi when backing-up my local host using .tar it would sometimes take 3
> days
> > > or more.
> > > I only know this because of disk usage.the hd led is constantly on. It
> > > this normal?
>
> I once experimented a lot with archiving the entire BackupPC data pool to
> tape (just tar'ing the whole thing up as one monolithic mass). Not exactly
> what you're doing, but it does provide a notable data point.
>
> - When I was using LVM snapshots, so that I didn't have to quiesce
> BackupPC,
> it would take 2 days to back up 200+GB.
> - When I stopped BackupPC before running the snapshot, let the tar
> command run, then re-started BackupPC afterwards, it took only perhaps 8
> hours.
>
> The upshot of this is to check:
>
> - Are you using LVM snapshots of anything? (probably not, but just
> asking).
> - How many backup processes do you have going simultaneously? (the default
> of '4' is too high).
> - Is the box doing anything else disk or processor-intensive?
> - Are you hitting swap?
> - Is swap on a disk other than your BackupPC data pool?
> - Is your BackupPC data pool on its own disk?
> - Is your data pool filesystem mounted noatime?
> - If using Reiserfs for your data pool filesystem, is it mounted notail?
> - If using a journaled filesystem which supports this, is the journal on a
> device other than the data pool device?
>
> --
> Carl Soderstrom
> Systems Administrator
> Real-Time Enterprises
> www.real-time.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
