Thanks for reading my whole email, Les! My comments are inline. On 5/25/2010 12:28 PM, Frank J. Gómez wrote: > > > > The last successful full backup of RED5 took just over 8 hours. 37,457 > > files totaling just under 25 GB were backed up at a rate of 0.87 > > MB/sec. RED5 is a laptop, and it's only on the network for about 8 > > hours per day, so I have to be able to do better than this. > > Is that the initial or 2nd run with this batch of files? The 3rd and > subsequent runs should be faster if you have enabled checksum caching. > Or is that a typical amount of change between backups? >
It is definitely not the initial run. The problem I've had with this particular client is that any full backup takes ages; the incremental backups work smoothly until the next full backup is scheduled. If the laptop stays in the office long enough for the next full backup to complete, then incrementals work fine; otherwise, the client seems to get stuck (for months, sometimes) trying to complete the partial. I don't think I have checksum caching enabled; I'll try that. Question (perhaps an obvious one): What is the benefit of doing periodic full backups? What would be the downside of getting the full backup once and then doing incrementals going forward? > Considering how cheap disks are these days, I like simple raid1 mirrors > where they are practical for the total size you need. > Could I gain any speed advantages by writing to more than one disk (striping, I guess they call it)? It seems like more disk heads might be able to do the job faster. > USB is as much the bottleneck as the drive. If you use externals, use > ESATA even if you have to add a card for it. > Yes, I meant that the fact I'm using it over USB is the bottleneck -- I don't even know if it's USB 2! I think internal is definitely the way to go for speed. > > Lastly, am I wrongheaded in trying to solve this problem with BackupPC? > Backuppc's rsync will be slower than stock because it is written in > perl, not the latest flavor, and works against a compressed copy on the > server. If speed of transfer from one or a few machines is your main > goal, you might provide server space for a full uncompressed copy where > you can rsync - then let backuppc back that up to keep its history in a > more efficient format. > That's an interesting idea. I'd prefer to stick with a more standard approach, but failing that I'll consider this option. > > -- > Les Mikesell > [email protected] > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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/ >
------------------------------------------------------------------------------
_______________________________________________ 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/
