Farmol SPA wrote at about 16:09:02 +0200 on Friday, August 20, 2010: > -------- Original Message -------- > Subject: Re: [BackupPC-users] Backup backuppc > From: Tyler J. Wagner <[email protected]> > To: [email protected] > Cc: Farmol SPA <[email protected]> > Date: Fri Aug 20 2010 15:00:37 GMT+0200 (ora Legale Europa Occidentale) > > On Friday 20 Aug 2010 12:32:10 Farmol SPA wrote: > >> A question: the source logical volume and the snapshot one must reside > >> in the same volume group for this feature to work? > > I believe a snapshot of a logical volume must necessarily reside in the > > same > > volume group, yes. So if you have an LV which is 100% of the VG, you must > > resize it down or add disks to make it larger. > > I made some tests and the snapshot must belong to the same vg of the > source lv. > > So, whenever I create the snapshot I have a "static" copy of the source > lv that I can copy with any method (eg rsync or netcat). At this point, > please forgive me, I don't see the advantage of LVM snapshots than using > directly the rsync approach on the "live" lv provided backuppc is > sleeping during this period. Provided there is no activity on the source > volume, how can the copy from the snaphost be faster than the direct > copy? is there any hidden mechanism that do the trick? > > Maybe I missed something.
Yes - you are missing something that multiple posters have tried to tell you. The problem is the number of hardlinks and not the amount of data. An LVM snapshot can copy block-by-block at near bare metal speed. Copying even 150GB takes only a matter of minutes on a fast machine. Rsync is file level copy and in particular needs to keep track of all the inodes in order to preserve hard links. This can take many, many hours for the same amount of data. As the data gets bigger, rsync may not even work or the time may expand to days. As has been stated MULTIPLE times on this group rsync is a very inefficient and ineffective way of copying the pool for any reasonably sized pool. We all wish it weren't, but it is. Read the archives to see what alternatives and future possibilities people have discussed. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ 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/
