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 <tyler AT tolaris DOT com>
 > To: backuppc-users AT lists.sourceforge DOT net
 > Cc: Farmol SPA <farmolspa AT gmail DOT com>
 > 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
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/