Re: [Iscsitarget-devel] Snapshots && LVM && IET

[Brian W. <br...@te...>]

When taking snapshots, you should follow the procedure below...

1: pause all daemons/processes that use the partition.
2: remount partition as RO  
3: create snapshot of partition
4: remount partition as RW
5: unpause all processes/daemons

step 1 and step 2 will typically force the server and most processes to
sync() the remaining write-back cache data to disk prior to the
snapshot. Typically this leaves you with only an "unmounted uncleanly"
flag on the backup snapshot filesystem.

This usually takes a mere 10 to 30 seconds to perform and is an
acceptable "down time" period for making backups.

Failure to follow the above procedure WILL result in an unclean and
probably corrupt snapshot that is worthless for backups.

This is taken from the IBM and Oracle guides to proper snapshot based
backup procedures.

Hope this information helps you. :)


On Fri, 2005-07-01 at 10:13 +0200, Arne Redlich wrote:
> Am Mittwoch, den 29.06.2005, 14:15 +0000 schrieb al...@po...:
> > I still have a problem with snapshots and IET. When I create a snapshot 
> > during coping data to LUN , LVM and system hangs. If I don`t copy data 
> > to LUN, all is alright.
> > To find a solution I've tried with blocking the session of the IET 
> > daemon by issueing the following command:
> > # /usr/sbin/ietadm --op delete --tid="tid" --sid="sid" --cid="cid"
> >  before creating snashot but it seems the session is actually not 
> > blocked (the behavior differs with version 0.4.5 which correctly blocks 
> > the session).
> > If I've tried with blocking a connection to individual lun:
> > # ietadm --op delete --tid=1 --lun=0
> > # lvcreate -l 100 -s -n nas_snap000 /dev/vg0/tgv000
> > # ietadm --op new --tid=1 --lun=0 --params /dev/vg0/tgv000
> > the system takes snapshot correctly and doesn't hang but the daemon 
> > resets the connection to the LUN snapshot is taken of. The problem is if 
> > a snapshot is to be  taken unnoticed to the user who currently is in 
> > use  of the share it would be nice the handle of the volume to be freed 
> > and the network operation suspended (but not reset). It seems like an 
> > LVM bug but  I've thought if such a workaround is possible?
> > 
> > Aluno3
> 
> Seems to be indeed a LVM2 problem - I just successfully took a snapshot
> of an evms[1]-volume while copying data to it via iSCSI (MSFT init /
> IET). Not sure if it is sensible to take snapshots while writing to a
> volume as you might end up with corrupted data in the snapshot?
> 
> [1] http://evms.sourceforge.net
>