I''m confused....I have a filesystem on server 1 called tank/nas/dump I made a snapshot called first zfs snapshot tank/nas/dump at first then i did a zfs send/recv like: zfs send tank/nas/dump at first | ssh wonslung at 192.168.1.xx "/bin/pfexec /usr/sbin/zfs recv tank/nas/dump" this worked fine, next today, i wanted to send what has changed.... i did zfs snapshot tank/nas/dump at second now, heres where i''m confused....from reading the man page i thought this command would work: pfexec zfs send -i tank/nas/dump at first tank/nas/dump at second| ssh wonslung at 192.168.1.15 "/bin/pfexec /usr/sbin/zfs recv -vd tank/nas/dump" but i get an error: cannot receive incremental stream: destination tank/nas/dump has been modified since most recent snapshot why is this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100522/b4aaf02f/attachment.html>
On 05/23/10 01:18 PM, Thomas Burgess wrote:> > this worked fine, next today, i wanted to send what has changed.... > > i did > zfs snapshot tank/nas/dump at second > > now, heres where i''m confused....from reading the man page i thought > this command would work: > > pfexec zfs send -i tank/nas/dump at first tank/nas/dump at second| ssh > wonslung at 192.168.1.15 <mailto:wonslung at 192.168.1.15> "/bin/pfexec > /usr/sbin/zfs recv -vd tank/nas/dump" >It should (you can shorten the first snap to "first".> > but i get an error: > > cannot receive incremental stream: destination tank/nas/dump has been > modified > since most recent snapshot >Well has it? Even wandering around the filesystem with atime enabled will cause this error. Add -f to the receive to force a roll-back to the state after the original snap. -- Ian.
On Sat, May 22, 2010 at 9:26 PM, Ian Collins <ian at ianshome.com> wrote:> On 05/23/10 01:18 PM, Thomas Burgess wrote: > >> >> this worked fine, next today, i wanted to send what has changed.... >> >> i did >> zfs snapshot tank/nas/dump at second >> >> now, heres where i''m confused....from reading the man page i thought this >> command would work: >> >> pfexec zfs send -i tank/nas/dump at first tank/nas/dump at second| ssh >> wonslung at 192.168.1.15 <mailto:wonslung at 192.168.1.15> "/bin/pfexec >> /usr/sbin/zfs recv -vd tank/nas/dump" >> >> It should (you can shorten the first snap to "first". > > >> but i get an error: >> >> cannot receive incremental stream: destination tank/nas/dump has been >> modified >> since most recent snapshot >> >> Well has it? Even wandering around the filesystem with atime enabled > will cause this error. > > Add -f to the receive to force a roll-back to the state after the original > snap. > > Ahh, this i didn''t know. Yes, i DID cd to the dir and check some stuff andatime IS enabled....this is NOT very intuitive. adding -F worked...thanks> -- > > Ian. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100522/6e740913/attachment.html>
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Thomas Burgess > > but i get an error: > > cannot receive incremental stream: destination tank/nas/dump has been > modified > since most recent snapshotWhenever you send a snap, and you intend to later receive an incremental, just make the filesystem read-only, to ensure you''ll be able to receive the incremental later. zfs set readonly=on somefilesystem
oh, this makes sense.... let me ask a question though. Lets say i have a filesystem tank/something i make the snapshot tank/something at one i send/recv it then i do something (add a file...remove something, whatever) on the send side, then i do a send/recv and force it of the next filesystem will the new recv''d filesystem be identical to the original forced snapshot or will it be a combination of the 2? On Sat, May 22, 2010 at 11:50 PM, Edward Ned Harvey <solaris2 at nedharvey.com>wrote:> > From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > > bounces at opensolaris.org] On Behalf Of Thomas Burgess > > > > but i get an error: > > > > cannot receive incremental stream: destination tank/nas/dump has been > > modified > > since most recent snapshot > > Whenever you send a snap, and you intend to later receive an incremental, > just make the filesystem read-only, to ensure you''ll be able to receive the > incremental later. > > zfs set readonly=on somefilesystem > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100522/22a4063c/attachment.html>
On 05/23/10 03:56 PM, Thomas Burgess wrote:> let me ask a question though. > > Lets say i have a filesystem > > tank/something > > i make the snapshot > > tank/something at one > > i send/recv it > > then i do something (add a file...remove something, whatever) on the > send side, then i do a send/recv and force it of the next filesystem >What do you mean "force it of the next filesystem"?> will the new recv''d filesystem be identical to the original forced > snapshot or will it be a combination of the 2?The received filesystem will be identical to the sending one. -- Ian.
ok, so forcing just basically makes it drop whatever "changes" were made Thats what i was wondering...this is what i expected On Sun, May 23, 2010 at 12:05 AM, Ian Collins <ian at ianshome.com> wrote:> On 05/23/10 03:56 PM, Thomas Burgess wrote: > >> let me ask a question though. >> >> Lets say i have a filesystem >> >> tank/something >> >> i make the snapshot >> >> tank/something at one >> >> i send/recv it >> >> then i do something (add a file...remove something, whatever) on the send >> side, then i do a send/recv and force it of the next filesystem >> >> What do you mean "force it of the next filesystem"? > > > will the new recv''d filesystem be identical to the original forced >> snapshot or will it be a combination of the 2? >> > > The received filesystem will be identical to the sending one. > > -- > Ian. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100523/ad012e40/attachment.html>
On Sat, May 22, 2010 at 9:08 PM, Thomas Burgess <wonslung at gmail.com> wrote:> ok, so forcing just basically makes it drop whatever "changes" were made > Thats what i was wondering...this is what i expectedIf you''re doing ''zfs send -i @first tank/foo/bar at second | zfs recv -F newtank/foo/bar'' then ''zfs recv -F'' is the same as doing ''zfs rollback newtank/foo/bar at first''. Any changes made on the newtank dataset will be lost. If you''ve done any snapshots on the received dataset (which is easy to do if you have the auto-snap service running) -F will not delete them. You''ll have to manually go in and rollback datasets to the start snapshot. -B -- Brandon High : bhigh at freaks.com