When I take a snapshot of a filesystem (or pool) and pass -r to get all
the sub-filesystems, am I getting the state of all the sub-filesystem
snapshots at the same instant, or is it essentially equivalent to
making the sub-filesystem snapshots one at a time as I would have to do
if -r weren't
On Sun, Feb 22, 2009 at 11:59 AM, David Abrahams d...@boostpro.com wrote:
When I take a snapshot of a filesystem (or pool) and pass -r to get all
the sub-filesystems, am I getting the state of all the sub-filesystem
snapshots at the same instant, or is it essentially equivalent to
making the
bup-ruin
# zfs send -R z...@bup-20090222-054457utc | zfs receive -dv
bup-ruin/fsfs/zp1
cannot receive: specified fs (bup-ruin/fsfs/zp1) does not exist
# zfs create bup-ruin/fsfs/zp1
# zfs send -R z...@bup-20090222-054457utc | zfs receive -dv
bup-ruin/fsfs/zp1
cannot receive new filesystem
on Wed Feb 18 2009, Frank Cusack fcusack-AT-fcusack.com wrote:
On February 17, 2009 3:57:34 PM -0800 Joe S js.li...@gmail.com wrote:
On Tue, Feb 17, 2009 at 3:35 PM, David Magda dma...@ee.ryerson.ca wrote:
If you want to do back ups of your file system use a documented utility
(tar, cpio,
import -R /backups/bup-ruin bup-ruin
# zfs send -R z...@bup-20090222-054457utc | zfs receive -dv
bup-ruin/fsfs/zp1
cannot receive: specified fs (bup-ruin/fsfs/zp1) does not exist
# zfs create bup-ruin/fsfs/zp1
# zfs send -R z...@bup-20090222-054457utc | zfs receive -dv
bup-ruin/fsfs/zp1
cannot
I thinks that's legitimate so long as you don't change ZFS versions.
Personally, I'm more comfortable doing a 'zfs send | zfs recv' than I
am storing the send stream itself. The problem I have with the stream
is that I may not be able to receive it in a future version of ZFS,
while I'm pretty
On Mon, Feb 23, 2009 at 11:33 AM, Blake blake.ir...@gmail.com wrote:
I thinks that's legitimate so long as you don't change ZFS versions.
Personally, I'm more comfortable doing a 'zfs send | zfs recv' than I
am storing the send stream itself. The problem I have with the stream
is that I may
da == David Abrahams d...@boostpro.com writes:
b == Blake blake.ir...@gmail.com writes:
da Has anyone here noticed that
da http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
da suggests in several places that zfs send streams be stored for
da backup?
Yup.
On February 22, 2009 1:14:44 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
(Note that I need to back up two pools, rpool and zp1, from the destkop on
the the single external pool bup-ruin. I'm importing bup-ruin with
altroot to avoid the mountoints of the backed-up filesystems on it
On Sun, February 22, 2009 16:31, Blake wrote:
I'm actually working on this for an application at my org. I'll try
to post my work somewhere when done (hopefully this week).
That'd be cool. I'm converting from rsync to send/receive because I
upgraded to 2008.11 and started using CIFS, so I
On Sun, February 22, 2009 18:11, Frank Cusack wrote:
On February 22, 2009 1:14:44 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
(Note that I need to back up two pools, rpool and zp1, from the destkop
on
the the single external pool bup-ruin. I'm importing bup-ruin with
altroot to avoid
On February 22, 2009 8:03:38 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
On Sun, February 22, 2009 18:11, Frank Cusack wrote:
Did you see my other thread on this specific topic? You can't backup
the root pool using zfs send -R | zfs recv.
Nope, somehow missed the import of that.
I'm
Agreed - I don't think that archiving simply the send stream is a
smart idea (yet, until the stream format is stabilized in some way).
I'd much rather archive to a normal ZFS filesystem. With ZFS's
enormous pool capacities, it's probably the closest thing we have
right now to a future-proof
Frank Cusack wrote:
When you try to backup the '/' part of the root pool, it will get
mounted on the altroot itself, which is of course already occupied.
At that point, the receive will fail.
So far as I can tell, mounting the received filesystem is the last
step in the process. So I guess
On Sun, February 22, 2009 21:06, Frank Cusack wrote:
On February 22, 2009 8:03:38 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
On Sun, February 22, 2009 18:11, Frank Cusack wrote:
Did you see my other thread on this specific topic? You can't backup
the root pool using zfs send -R | zfs
I even vaguely think I've done it before, but maybe it was against some
other component.
Anyway, the obvious place I find is
http://www.opensolaris.org/bug/report.jspa, but the categories don't
include either zfs or filesystems or anything that it makes sense to
me that ZFS might be under.
I've
On Sun, 22 Feb 2009 22:05:57 -0600 (CST)
David Dyer-Bennet d...@dd-b.net wrote:
I even vaguely think I've done it before, but maybe it was against some
other component.
Anyway, the obvious place I find is
http://www.opensolaris.org/bug/report.jspa, but the categories don't
include either
Dave wrote:
Frank Cusack wrote:
When you try to backup the '/' part of the root pool, it will get
mounted on the altroot itself, which is of course already occupied.
At that point, the receive will fail.
So far as I can tell, mounting the received filesystem is the last
step in the
On February 22, 2009 9:56:02 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
On Sun, February 22, 2009 21:06, Frank Cusack wrote:
On February 22, 2009 8:03:38 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
On Sun, February 22, 2009 18:11, Frank Cusack wrote:
Did you see my other thread on
On February 22, 2009 10:05:57 PM -0600 David Dyer-Bennet d...@dd-b.net
wrote:
I've got this pretty definite problem with zfs receive -d; I've posted
examples before, but here's the cleanest one so far. This shows carefully
what's where, and shows that zfs receive -d first refuses to receive
20 matches
Mail list logo
