Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
erik.ableson said: "Just a quick comment for the send/recv operations, adding -R makes it recursive so you only need one line to send the rpool and all descendant filesystems. " Yes, I know of the -R flag, but it doesn't seem to work with sending loose snapshots to the backup pool. It obviously works when piped to a file. Sorry I can't remember what the error message was when I tried to 'send -R | receive backup-pool/rpool', it does work if done individually though. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> Just a quick comment for the send/recv operations, adding -R makes it > recursive so you only need one line to send the rpool and all descendant > filesystems. Yes, I am aware of that, but it does not work when you are sending them loose to an existing pool. Can't remember the error message but it didn't work for me. It seems to work fine when redirecting to standard output ( > somefile.bck) or in your case piping it through gzip and then output to a file. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Hi Bob, You can review the latest Solaris 10 and OpenSolaris release dates here: http://www.oracle.com/ocom/groups/public/@ocom/documents/webcontent/059542.pdf Solaris 10 release, CY2010 OpenSolaris release, 1st half CY2010 Thanks, Cindy On 05/05/10 18:03, Bob Friesenhahn wrote: On Wed, 5 May 2010, Ray Van Dolson wrote: From a zfs standpoint, Solaris 10 does not seem to be behind the currently supported OpenSolaris release. Well, being able to remove ZIL devices is one important feature missing. Hopefully in U9. :) While the development versions of OpenSolaris are clearly well beyond Solaris 10, I don't believe that the supported version of OpenSolaris (a year old already) has this feature yet either and Solaris 10 has been released several times since then already. When the forthcoming OpenSolaris release emerges in 2011, the situation will be far different. Solaris 10 can then play catch-up with the release of U9 in 2012. Bob ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Ray Van Dolson > > Well, being able to remove ZIL devices is one important feature > missing. Hopefully in U9. :) I did have a support rep confirm for me that both the log device removal, and the ability to mirror slightly smaller devices will be present in U9. But he couldn't say when that would be. And if I happen to remember my facts wrong (or not remember my facts when I think I do) ... Please throw no stones. ;-) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Bob Friesenhahn > > From a zfs standpoint, Solaris 10 does not seem to be behind the > currently supported OpenSolaris release. I'm sorry, I'll have to disagree with you there. In solaris 10, fully updated, you can only get up to zpool version 15. This is lacking many later features ... For me in particular, zpool 19 is when "zpool remove log" was first supported. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Wed, May 05, 2010 at 05:09:40PM -0700, Erik Trimble wrote: > On Wed, 2010-05-05 at 19:03 -0500, Bob Friesenhahn wrote: > > On Wed, 5 May 2010, Ray Van Dolson wrote: > > >> > > >> From a zfs standpoint, Solaris 10 does not seem to be behind the > > >> currently supported OpenSolaris release. > > > > > > Well, being able to remove ZIL devices is one important feature > > > missing. Hopefully in U9. :) > > > > While the development versions of OpenSolaris are clearly well beyond > > Solaris 10, I don't believe that the supported version of OpenSolaris > > (a year old already) has this feature yet either and Solaris 10 has > > been released several times since then already. When the forthcoming > > OpenSolaris release emerges in 2011, the situation will be far > > different. Solaris 10 can then play catch-up with the release of U9 > > in 2012. > > > > Bob > > Pessimist. ;-) > > > s/2011/2010/ > s/2012/2011/ > Yeah, U9 in 2012 makes me very sad. I would really love to see the hot-removable ZIL's this year. Otherwise I'll need to rebuild a few zpools :) Ray ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Wed, 2010-05-05 at 19:03 -0500, Bob Friesenhahn wrote: > On Wed, 5 May 2010, Ray Van Dolson wrote: > >> > >> From a zfs standpoint, Solaris 10 does not seem to be behind the > >> currently supported OpenSolaris release. > > > > Well, being able to remove ZIL devices is one important feature > > missing. Hopefully in U9. :) > > While the development versions of OpenSolaris are clearly well beyond > Solaris 10, I don't believe that the supported version of OpenSolaris > (a year old already) has this feature yet either and Solaris 10 has > been released several times since then already. When the forthcoming > OpenSolaris release emerges in 2011, the situation will be far > different. Solaris 10 can then play catch-up with the release of U9 > in 2012. > > Bob Pessimist. ;-) s/2011/2010/ s/2012/2011/ -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Wed, 5 May 2010, Ray Van Dolson wrote: From a zfs standpoint, Solaris 10 does not seem to be behind the currently supported OpenSolaris release. Well, being able to remove ZIL devices is one important feature missing. Hopefully in U9. :) While the development versions of OpenSolaris are clearly well beyond Solaris 10, I don't believe that the supported version of OpenSolaris (a year old already) has this feature yet either and Solaris 10 has been released several times since then already. When the forthcoming OpenSolaris release emerges in 2011, the situation will be far different. Solaris 10 can then play catch-up with the release of U9 in 2012. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Wed, May 05, 2010 at 04:31:08PM -0700, Bob Friesenhahn wrote: > On Thu, 6 May 2010, Ian Collins wrote: > >> Bob and Ian are right. I was trying to remember the last time I installed > >> Solaris 10, and the best I can recall, it was around late fall 2007. > >> The fine folks at Oracle have been making improvements to the product > >> since then, even though no new significant features have been added since > >> that time :-( > >> > > ZFS boot? > > I think that Richard is referring to the fact that the PowerPC/Cell > Solaris 10 port for the Sony Playstation III never emerged. ;-) > > Other than desktop features, as a Solaris 10 user I have seen > OpenSolaris kernel features continually percolate down to Solaris 10 > so I don't feel as left out as Richard would like me to feel. > > From a zfs standpoint, Solaris 10 does not seem to be behind the > currently supported OpenSolaris release. > > Bob Well, being able to remove ZIL devices is one important feature missing. Hopefully in U9. :) Ray ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Thu, 6 May 2010, Ian Collins wrote: Bob and Ian are right. I was trying to remember the last time I installed Solaris 10, and the best I can recall, it was around late fall 2007. The fine folks at Oracle have been making improvements to the product since then, even though no new significant features have been added since that time :-( ZFS boot? I think that Richard is referring to the fact that the PowerPC/Cell Solaris 10 port for the Sony Playstation III never emerged. ;-) Other than desktop features, as a Solaris 10 user I have seen OpenSolaris kernel features continually percolate down to Solaris 10 so I don't feel as left out as Richard would like me to feel. From a zfs standpoint, Solaris 10 does not seem to be behind the currently supported OpenSolaris release. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On 05/ 6/10 05:32 AM, Richard Elling wrote: On May 4, 2010, at 7:55 AM, Bob Friesenhahn wrote: On Mon, 3 May 2010, Richard Elling wrote: This is not a problem on Solaris 10. It can affect OpenSolaris, though. That's precisely the opposite of what I thought. Care to explain? In Solaris 10, you are stuck with LiveUpgrade, so the root pool is not shared with other boot environments. Richard, You have fallen out of touch with Solaris 10, which is still a moving target. While the Live Upgrade commands you are familiar with in Solaris 10 still mostly work as before, they *do* take advantage of zfs's features and boot environments do share the same root pool just like in OpenSolaris. Solaris 10 Live Upgrade is dramatically improved in conjunction with zfs boot. I am not sure how far behind it is from OpenSolaris new boot administration tools but under zfs its function can not be terribly different. Bob and Ian are right. I was trying to remember the last time I installed Solaris 10, and the best I can recall, it was around late fall 2007. The fine folks at Oracle have been making improvements to the product since then, even though no new significant features have been added since that time :-( ZFS boot? -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On May 4, 2010, at 7:55 AM, Bob Friesenhahn wrote: > On Mon, 3 May 2010, Richard Elling wrote: This is not a problem on Solaris 10. It can affect OpenSolaris, though. >>> >>> That's precisely the opposite of what I thought. Care to explain? >> >> In Solaris 10, you are stuck with LiveUpgrade, so the root pool is >> not shared with other boot environments. > > Richard, > > You have fallen out of touch with Solaris 10, which is still a moving target. > While the Live Upgrade commands you are familiar with in Solaris 10 still > mostly work as before, they *do* take advantage of zfs's features and boot > environments do share the same root pool just like in OpenSolaris. Solaris > 10 Live Upgrade is dramatically improved in conjunction with zfs boot. I am > not sure how far behind it is from OpenSolaris new boot administration tools > but under zfs its function can not be terribly different. Bob and Ian are right. I was trying to remember the last time I installed Solaris 10, and the best I can recall, it was around late fall 2007. The fine folks at Oracle have been making improvements to the product since then, even though no new significant features have been added since that time :-( -- richard -- ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Mon, 3 May 2010, Richard Elling wrote: This is not a problem on Solaris 10. It can affect OpenSolaris, though. That's precisely the opposite of what I thought. Care to explain? In Solaris 10, you are stuck with LiveUpgrade, so the root pool is not shared with other boot environments. Richard, You have fallen out of touch with Solaris 10, which is still a moving target. While the Live Upgrade commands you are familiar with in Solaris 10 still mostly work as before, they *do* take advantage of zfs's features and boot environments do share the same root pool just like in OpenSolaris. Solaris 10 Live Upgrade is dramatically improved in conjunction with zfs boot. I am not sure how far behind it is from OpenSolaris new boot administration tools but under zfs its function can not be terribly different. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Mon, 3 May 2010, Edward Ned Harvey wrote: That's precisely the opposite of what I thought. Care to explain? If you have a primary OS disk, and you apply OS Updates ... in order to access those updates in Sol10, you need a registered account and login, with paid solaris support. Then, if you boot a removable hard disk, and you wish to apply updates to keep it at the same rev as the primary OS ... you've got to once again enter your Sol10 update download credentials, and I don't presume it works, or will always work for a 2nd installation of Sol10. Aren't you supposed to pay for support on each OS installation? Doesn't that mean you'd have to pay a separate support contract for the removable boot hard drive? The Solaris 10 licensing situation has changed dramatically in recent months. It used to be that anyone was always eligible for security updates and the core kernel was always marked as a security update. Now the only eligibility for use of Solaris 10 is either via an existing service contract, or an interim 90-day period (with registration) intended for product evaluation. It is pretty common for the Solaris 10 installation from media to support an older version of zfs than the kernel now running on the system (which was updated via a patch). Due to the new Solaris 10 license and the potential need to download and apply a patch, issues emerge if this maintenance needs to be done after a service contract (or the 90-day eval entitlement) has expired. As a result, it is wise for Solaris 10 users to maintain a local repository of licensed patches in case their service contract should expire. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On 05/ 4/10 03:39 PM, Richard Elling wrote: On May 3, 2010, at 7:55 PM, Edward Ned Harvey wrote: From: Richard Elling [mailto:richard.ell...@gmail.com] Once you register your original Solaris 10 OS for updates, are you unable to get updates on the removable OS? This is not a problem on Solaris 10. It can affect OpenSolaris, though. That's precisely the opposite of what I thought. Care to explain? In Solaris 10, you are stuck with LiveUpgrade, so the root pool is not shared with other boot environments. All the LU BEs live in the root pool. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On May 3, 2010, at 7:55 PM, Edward Ned Harvey wrote: >> From: Richard Elling [mailto:richard.ell...@gmail.com] >> >>> Once you register your original Solaris 10 OS for updates, are >>> you >>> unable to get updates on the removable OS? >> >> This is not a problem on Solaris 10. It can affect OpenSolaris, though. > > That's precisely the opposite of what I thought. Care to explain? In Solaris 10, you are stuck with LiveUpgrade, so the root pool is not shared with other boot environments. -- richard > If you have a primary OS disk, and you apply OS Updates ... in order to > access those updates in Sol10, you need a registered account and login, with > paid solaris support. Then, if you boot a removable hard disk, and you wish > to apply updates to keep it at the same rev as the primary OS ... you've got > to once again enter your Sol10 update download credentials, and I don't > presume it works, or will always work for a 2nd installation of Sol10. > Aren't you supposed to pay for support on each OS installation? Doesn't > that mean you'd have to pay a separate support contract for the removable > boot hard drive? > > But in opensolaris, updates are free. Don't require any login credentials. > So if you update your primary OS, I see nothing to prevent you from booting > your removable disk, and applying the same updates to the 2nd OS. > > -- ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: Richard Elling [mailto:richard.ell...@gmail.com] > > > Once you register your original Solaris 10 OS for updates, are > > you > > unable to get updates on the removable OS? > > This is not a problem on Solaris 10. It can affect OpenSolaris, though. That's precisely the opposite of what I thought. Care to explain? If you have a primary OS disk, and you apply OS Updates ... in order to access those updates in Sol10, you need a registered account and login, with paid solaris support. Then, if you boot a removable hard disk, and you wish to apply updates to keep it at the same rev as the primary OS ... you've got to once again enter your Sol10 update download credentials, and I don't presume it works, or will always work for a 2nd installation of Sol10. Aren't you supposed to pay for support on each OS installation? Doesn't that mean you'd have to pay a separate support contract for the removable boot hard drive? But in opensolaris, updates are free. Don't require any login credentials. So if you update your primary OS, I see nothing to prevent you from booting your removable disk, and applying the same updates to the 2nd OS. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
more below... On May 3, 2010, at 2:22 PM, Edward Ned Harvey wrote: >> From: Cindy Swearingen [mailto:cindy.swearin...@oracle.com] >> Sent: Monday, May 03, 2010 12:58 PM >> >> Hi Ned, >> >> Yes, I agree that it is a good idea not to update your root pool >> version before restoring your existing root pool snapshots. >> >> If you are using a later Solaris OS to recover your pool and root pool >> snapshots, you can alway create the pool with a specific version, like >> this: >> >> # zpool create -o version=19 rpool c1t3d0s0 >> >> I will add this info to the root pool recovery process. >> >> Thanks for the feedback... > > But if you unfortunately had a necessity to upgrade your rpool version ... > Such as I recently did, when my replacement log device was 1Mb smaller than > the device it was intended to mirror ... The most graceful way I can think > to handle that zpool upgrade would be to also install solaris/opensolaris to > a removable disk, and *test* that you can boot from it. This way, when you > update your primary OS and then update the zpool ... You can also update the > removable OS, and rest assured you've got a bootable removable media which > supports the necessary zpool version, so you have actually some option > available to restore rpool in the event of failure. > > But this technique sounds like it leaves a lot of possible failures... Such > as ... Once you register your original Solaris 10 OS for updates, are you > unable to get updates on the removable OS? This is not a problem on Solaris 10. It can affect OpenSolaris, though. > Does sparc support booting removable hard disks? Yes, though it is trivial (and easier) to boot from the net. > And even on the x86, which support booting the removable media, I've > certainly seen little "gotchas" such as "Well, it *should* work..." well... maybe you get what you pay for? :-) > And I recently had a server where I was able to install Solaris 10, but > couldn't install opensolaris due to driver incompatibility. So while that's > presumably unusual, it's certainly nonzero. Be sure to file a bug. That said, there has been a move recently to EOF some old drivers. If you file a bug against archaic hardware drivers, don't be surprised if they are EOF. > So I think the take-away knowledge here is: If you *must* upgrade your > rpool version, and you want to be able to restore your rpool from a backup, > it's recommended (perhaps critical) that you also maintain a removable OS > which supports the necessary hardware and rpool version, because without it, > you might have no viable restore procedure. Test it. This is SOP, no? -- richard ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: Cindy Swearingen [mailto:cindy.swearin...@oracle.com] > Sent: Monday, May 03, 2010 12:58 PM > > Hi Ned, > > Yes, I agree that it is a good idea not to update your root pool > version before restoring your existing root pool snapshots. > > If you are using a later Solaris OS to recover your pool and root pool > snapshots, you can alway create the pool with a specific version, like > this: > > # zpool create -o version=19 rpool c1t3d0s0 > > I will add this info to the root pool recovery process. > > Thanks for the feedback... But if you unfortunately had a necessity to upgrade your rpool version ... Such as I recently did, when my replacement log device was 1Mb smaller than the device it was intended to mirror ... The most graceful way I can think to handle that zpool upgrade would be to also install solaris/opensolaris to a removable disk, and *test* that you can boot from it. This way, when you update your primary OS and then update the zpool ... You can also update the removable OS, and rest assured you've got a bootable removable media which supports the necessary zpool version, so you have actually some option available to restore rpool in the event of failure. But this technique sounds like it leaves a lot of possible failures... Such as ... Once you register your original Solaris 10 OS for updates, are you unable to get updates on the removable OS? Does sparc support booting removable hard disks? And even on the x86, which support booting the removable media, I've certainly seen little "gotchas" such as "Well, it *should* work..." And I recently had a server where I was able to install Solaris 10, but couldn't install opensolaris due to driver incompatibility. So while that's presumably unusual, it's certainly nonzero. So I think the take-away knowledge here is: If you *must* upgrade your rpool version, and you want to be able to restore your rpool from a backup, it's recommended (perhaps critical) that you also maintain a removable OS which supports the necessary hardware and rpool version, because without it, you might have no viable restore procedure. Test it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Hi Ned, Yes, I agree that it is a good idea not to update your root pool version before restoring your existing root pool snapshots. If you are using a later Solaris OS to recover your pool and root pool snapshots, you can alway create the pool with a specific version, like this: # zpool create -o version=19 rpool c1t3d0s0 I will add this info to the root pool recovery process. Thanks for the feedback... Cindyr On 04/30/10 22:46, Edward Ned Harvey wrote: From: Cindy Swearingen [mailto:cindy.swearin...@oracle.com] Sent: Friday, April 30, 2010 10:46 AM Hi Ned, Unless I misunderstand what bare metal recovery means, the following procedure describes how to boot from CD, recreate the root pool, and restore the root pool snapshots: http://docs.sun.com/app/docs/doc/819-5461/ghzur?l=en&a=view I retest this process at every Solaris release. You are awesome. ;-) When I said I was 90% certain, it turns out, that was a spot-on assessment of my own knowledge. I did not know about setting the "bootfs" property. I see that you are apparently storing the "zfs send" datastream in a file. Of course, discouraged, but no problem as long as it's no problem. I personally prefer to "zfs send | zfs receive" directly onto removable storage. One more really important gotcha. Let's suppose the version of zfs on the CD supports up to zpool 14. Let's suppose your "live" system had been fully updated before crash, and let's suppose the zpool had been upgraded to zpool 15. Wouldn't that mean it's impossible to restore your rpool using the CD? Wouldn't it mean it's impossible to restore the rpool using anything other than a fully installed, and at least moderately updated on-hard-disk OS? Maybe you could fully install onto hard disk 2 of the system, and then upgrade, and then use that OS to restore the rpool onto disk 1 of the system... Would that be fuel to recommend people, "Never upgrade your version of zpool or zfs on your rpool?" ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us] > Sent: Saturday, May 01, 2010 7:07 PM > > On Sat, 1 May 2010, Peter Tribble wrote: > >> > >> With the new Oracle policies, it seems unlikely that you will be > able to > >> reinstall the OS and achieve what you had before. > > > > And what policies have Oracle introduced that mean you can't > reinstall > > your system? > > The main concern is that you might not be able to get back the same OS > install you had before due to loss of patch access after your service > contract has expired and Oracle arbitrarily decided not to grant you a > new one. It's as if you didn't even read this thread. In the proposed answers to Euan's question, there is no need to apply any patches, or to have any service contract. As long as you still have your OS install CD, or *any* OS install CD, you install a throw-away OS, just for the sake of letting the installer create the partitions, boot record, boot properties, etc... And then you immediately obliterate and overwrite rpool, using your backup image. Since this restoration process puts the filesystem back into the exact state it was before failure ... All the patches you previously had are restored, and everything is restored just as it was before crash. There is nothing anywhere which indicates any reason you couldn't do this, even in the future. So you're totally spreading BS on this one. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Sat, 1 May 2010, Peter Tribble wrote: With the new Oracle policies, it seems unlikely that you will be able to reinstall the OS and achieve what you had before. And what policies have Oracle introduced that mean you can't reinstall your system? The main concern is that you might not be able to get back the same OS install you had before due to loss of patch access after your service contract has expired and Oracle arbitrarily decided not to grant you a new one. Maybe if you are able to overwrite the pool with the original pristine state rather than rely on an "install", then you would be ok. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On 05/ 1/10 04:46 PM, Edward Ned Harvey wrote: One more really important gotcha. Let's suppose the version of zfs on the CD supports up to zpool 14. Let's suppose your "live" system had been fully updated before crash, and let's suppose the zpool had been upgraded to zpool 15. Wouldn't that mean it's impossible to restore your rpool using the CD? Just make sure you have an up to date live CD when you upgrade your pool. It's seldom wise to upgrade a pool too quickly after an OS upgrade, you may find an issue and have to revert back to a previous BE. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Fri, Apr 30, 2010 at 6:39 PM, Bob Friesenhahn wrote: > On Thu, 29 Apr 2010, Edward Ned Harvey wrote: >> >> This is why I suggested the technique of: >> Reinstall the OS just like you did when you first built your machine, >> before >> the catastrophy. It doesn't even matter if you make the same selections >> you > > With the new Oracle policies, it seems unlikely that you will be able to > reinstall the OS and achieve what you had before. And what policies have Oracle introduced that mean you can't reinstall your system? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Sat, 1 May 2010, Edward Ned Harvey wrote: Would that be fuel to recommend people, "Never upgrade your version of zpool or zfs on your rpool?" It does seem to be a wise policy to not update the pool and filesystem versions unless you require a new pool or filesystem feature. Then you would update to the minimum version required to support that feature. Note that if the default filesystem version changes and you create a new filesystem, this may also cause problems (I have been bit by that before). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us] > Sent: Friday, April 30, 2010 1:40 PM > > With the new Oracle policies, it seems unlikely that you will be able > to reinstall the OS and achieve what you had before. An exact > recovery method (dd of partition images or recreate pool with 'zfs > receive') seems like the only way to be assured of recovery moving > forward. What??? Confusing parts: "the new Oracle policies" "unlikely that you will be able to reinstall the OS and achieve what you had before" Didn't you see Cindy's post? Would you like to point out any specific flaws in what was written, that I guess she probably wrote? In particular, I found the following to be very valuable: > From: Cindy Swearingen [mailto:cindy.swearin...@oracle.com] > > the following > procedure describes how to boot from CD, recreate the root pool, and > restore the root pool snapshots: > > http://docs.sun.com/app/docs/doc/819-5461/ghzur?l=en&a=view > > I retest this process at every Solaris release. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: Cindy Swearingen [mailto:cindy.swearin...@oracle.com] > Sent: Friday, April 30, 2010 10:46 AM > > Hi Ned, > > Unless I misunderstand what bare metal recovery means, the following > procedure describes how to boot from CD, recreate the root pool, and > restore the root pool snapshots: > > http://docs.sun.com/app/docs/doc/819-5461/ghzur?l=en&a=view > > I retest this process at every Solaris release. You are awesome. ;-) When I said I was 90% certain, it turns out, that was a spot-on assessment of my own knowledge. I did not know about setting the "bootfs" property. I see that you are apparently storing the "zfs send" datastream in a file. Of course, discouraged, but no problem as long as it's no problem. I personally prefer to "zfs send | zfs receive" directly onto removable storage. One more really important gotcha. Let's suppose the version of zfs on the CD supports up to zpool 14. Let's suppose your "live" system had been fully updated before crash, and let's suppose the zpool had been upgraded to zpool 15. Wouldn't that mean it's impossible to restore your rpool using the CD? Wouldn't it mean it's impossible to restore the rpool using anything other than a fully installed, and at least moderately updated on-hard-disk OS? Maybe you could fully install onto hard disk 2 of the system, and then upgrade, and then use that OS to restore the rpool onto disk 1 of the system... Would that be fuel to recommend people, "Never upgrade your version of zpool or zfs on your rpool?" ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On Thu, 29 Apr 2010, Edward Ned Harvey wrote: This is why I suggested the technique of: Reinstall the OS just like you did when you first built your machine, before the catastrophy. It doesn't even matter if you make the same selections you With the new Oracle policies, it seems unlikely that you will be able to reinstall the OS and achieve what you had before. An exact recovery method (dd of partition images or recreate pool with 'zfs receive') seems like the only way to be assured of recovery moving forward. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
On 30 avr. 2010, at 13:47, Euan Thoms wrote: > Well I'm so impressed with zfs at the moment! I just got steps 5 and 6 (form > my last post) to work, and it works well. Not only does it send the increment > over to the backup drive, the latest increment/snapshot appears in the > mounted filesystem. In nautilus I can browse an exact copy of my PC, from / > to the deepest parts of my home folder. And it will backup my entire system > in 1-2 minutes, AMAZING!! > > Below are the steps, try it for yourself on a spare USB HDD: > > # Create backup storage pool on drive c12t0d0 > pfexec zpool create backup-pool c12t0d0 > # Recursively snapshot the root pool (rpool) > pfexec zfs snapshot -r rp...@first > > # Send the entire pool in all it's snapshots to the backup pool, disable > mounting > pfexec zfs send rp...@first | pfexec zfs receive -u backup-pool/rpool > [snip ]pfexec zfs send rpool/export/home/euan/vbox-...@first | pfexec zfs > receive -u backup-pool/rpool/export/home/euan/VBOX-HDD > > # Take second snapshot at a later point in time > pfexec zfs snapshot -r rp...@second > > # Send the increments to the backup pool > pfexec zfs send -i rpool/r...@first rpool/r...@second | pfexec zfs recv -F > backup-pool/rpool/ROOT > [snip > ]pfexec zfs send -i rpool/export/home/euan/downlo...@first > rpool/export/home/euan/downlo...@second | pfexec zfs recv -F > backup-pool/rpool/export/home/euan/Downloads Just a quick comment for the send/recv operations, adding -R makes it recursive so you only need one line to send the rpool and all descendant filesystems. I use the send/recv operations for all sorts of backup operations. For the equivalent of a "full backup" of my boot volumes : NOW=`date +%Y-%m-%d_%H-%M-%S` pfexec /usr/sbin/zfs snapshot -r rp...@$now pfexec /usr/sbin/zfs send –R rp...@now | /usr/bin/gzip > /mnt/backups/rpool.$NOW.zip pfexec /usr/sbin/zfs destroy -r rp...@$now But for any incremental transfers it's better to recv to an actual filesystem that you can scrub and confirm that the stream made it over OK. Cheers, Erik___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Hi Ned, Unless I misunderstand what bare metal recovery means, the following procedure describes how to boot from CD, recreate the root pool, and restore the root pool snapshots: http://docs.sun.com/app/docs/doc/819-5461/ghzur?l=en&a=view I retest this process at every Solaris release. Thanks, Cindy On 04/29/10 21:42, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Cindy Swearingen For full root pool recovery see the ZFS Administration Guide, here: http://docs.sun.com/app/docs/doc/819-5461/ghzvz?l=en&a=view Recovering the ZFS Root Pool or Root Pool Snapshots Unless I misunderstand, I think the intent of the OP question is how to do bare metal recovery after some catastrophic failure. In this situation, recovery is much more complex than what the ZFS Admin Guide says above. You would need to boot from CD, and partition and format the disk, then create a pool, and create a filesystem, and "zfs send | zfs receive" into that filesystem, and finally install the boot blocks. Only some of these steps are described in the ZFS Admin Guide, because simply expanding the rpool is a fundamentally easier thing to do. Even though I think I could do that ... I don't have a lot of confidence in it, and I can certainly imagine some pesky little detail being a problem. This is why I suggested the technique of: Reinstall the OS just like you did when you first built your machine, before the catastrophy. It doesn't even matter if you make the same selections you made before (IP address, package selection, authentication method, etc) as long as you're choosing to partition and install the bootloader like you did before. This way, you're sure the partitions, format, pool, filesystem, and bootloader are all configured properly. Then boot from CD again, and "zfs send | zfs receive" to overwrite your existing rpool. And as far as I know, that will take care of everything. But I only feel like 90% confident that would work. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Euan Thoms > > pfexec zfs send rp...@first | pfexec zfs receive -u backup-pool/rpool > pfexec zfs send rpool/r...@first | pfexec zfs receive -u backup- > pool/rpool/ROOT > pfexec zfs send rpool/ROOT/opensolaris-2009.06-...@first | pfexec zfs > receive -u backup-pool/rpool/ROOT/OpenSolaris-2009.06-134 > pfexec zfs send rpool/d...@first | pfexec zfs receive -u backup- > pool/rpool/dump (and so on) I notice you have many zfs filesystems inside of other zfs filesystems. While this is common practice, I will personally advise against it in general, unless you can name a reason why you want to do that. Here is one reason not to do that: If you're working in some directory, and you want to access a snapshot of some file you're working on, you have to go up to the root of the filesystem that you're currently in. If you go up too far and find a .zfs directory in some filesystem which is above your current filesystem, then you can't find your snapshots. You have to know precisely which is the right .zfs directory to go into. Also, as you've demonstrated, it makes your backup scripts much longer. > #pfexec zfs umount backup-pool/rpool/export/home/euan/VBOX-HDD > #pfexec zfs umount backup-pool/rpool/export/home/euan/Downloads Instead of mounting & unmounting the external zfs filesystems, I would recommend importing & exporting the external zpool. No need to mount/unmount. It's automatic by zpool import/export. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Euan Thoms > > My ideal solution would be to have the data accessible from the backup > media (external HDD) as well as be used as full syatem restore. Below > is what I would consider ideal: > > 1.) Create a pool on an external HDD called backup-pool > 2.) Send the whole rpool (all filesystems within) to the backup pool. > 3.) be able to browse the backup pool starting from /backup-pool > 4.) be able to export the backup pool and import on PC2 to browse the > files there > 5.) be able to create another snapshot of rpool and "zfs snapshot -i > rp...@first-snapshot rp...@next-snapshot backup-pool/rpool" (send the > increment to the backup pool/drive > 6.) be able to browse the latest snapshot data on the backup drive, > whilst able to clone an older snapsho > 7.) be able to 'zfs send' the latest backup snapshot to a fresh > installation, thus get it back to exactly how it was before disaster. Yes, all of the above are possible. This is what I personally do. > However, it's step 7 that I have no idea if it will work. Edward, your > post gives me promise, 90% confidence is a good start. The remaining 10% is: Although I know for sure you can do all your backups as described above, I have not attempted the bare metal restore. Although I believe I understand all that's needed about partitions, boot labels, etc, I must acknowledge some uncertainty about precisely the best method of doing the bare metal restore. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Well I'm so impressed with zfs at the moment! I just got steps 5 and 6 (form my last post) to work, and it works well. Not only does it send the increment over to the backup drive, the latest increment/snapshot appears in the mounted filesystem. In nautilus I can browse an exact copy of my PC, from / to the deepest parts of my home folder. And it will backup my entire system in 1-2 minutes, AMAZING!! Below are the steps, try it for yourself on a spare USB HDD: >>> # Create backup storage pool on drive c12t0d0 pfexec zpool create backup-pool c12t0d0 # Recursively snapshot the root pool (rpool) pfexec zfs snapshot -r rp...@first # Send the entire pool in all it's snapshots to the backup pool, disable mounting pfexec zfs send rp...@first | pfexec zfs receive -u backup-pool/rpool pfexec zfs send rpool/r...@first | pfexec zfs receive -u backup-pool/rpool/ROOT pfexec zfs send rpool/ROOT/opensolaris-2009.06-...@first | pfexec zfs receive -u backup-pool/rpool/ROOT/OpenSolaris-2009.06-134 pfexec zfs send rpool/d...@first | pfexec zfs receive -u backup-pool/rpool/dump pfexec zfs send rpool/s...@first | pfexec zfs receive -u backup-pool/rpool/swap pfexec zfs send rpool/websp...@first | pfexec zfs receive -u backup-pool/rpool/webspace pfexec zfs send rpool/exp...@first | pfexec zfs receive -u backup-pool/rpool/export pfexec zfs send rpool/export/h...@first | pfexec zfs receive -u backup-pool/rpool/export/home pfexec zfs send rpool/export/home/e...@first | pfexec zfs receive -u backup-pool/rpool/export/home/euan pfexec zfs send rpool/export/home/euan/downlo...@first | pfexec zfs receive -u backup-pool/rpool/export/home/euan/Downloads pfexec zfs send rpool/export/home/euan/vbox-...@first | pfexec zfs receive -u backup-pool/rpool/export/home/euan/VBOX-HDD # Change mount points to correct structure pfexec zfs set mountpoint=legacy backup-pool/rpool/ROOT pfexec zfs set mountpoint=/backup-pool/opensolaris backup-pool/rpool/ROOT/OpenSolaris-2009.06-134 pfexec zfs set mountpoint=/backup-pool/opensolaris/rpool backup-pool/rpool pfexec zfs set mountpoint=/backup-pool/opensolaris/opt/webspace backup-pool/rpool/webspace pfexec zfs set mountpoint=/backup-pool/opensolaris/export backup-pool/rpool/export pfexec zfs set mountpoint=/backup-pool/opensolaris/export/home backup-pool/rpool/export/home pfexec zfs set mountpoint=/backup-pool/opensolaris/export/home/euan backup-pool/rpool/export/home/euan pfexec zfs set mountpoint=/backup-pool/opensolaris/export/home/euan/Downloads backup-pool/rpool/export/home/euan/Downloads pfexec zfs set mountpoint=/backup-pool/opensolaris/export/home/euan/VBOX-HDD backup-pool/rpool/export/home/euan/VBOX-HDD # Now we can mount the backup pool filesystems pfexec zfs mount backup-pool/rpool/ROOT/OpenSolaris-2009.06-134 pfexec zfs mount backup-pool/rpool pfexec zfs mount backup-pool/rpool/webspace pfexec zfs mount backup-pool/rpool/export pfexec zfs mount backup-pool/rpool/export/home pfexec zfs mount backup-pool/rpool/export/home/euan pfexec zfs mount backup-pool/rpool/export/home/euan/Downloads pfexec zfs mount backup-pool/rpool/export/home/euan/VBOX-HDD # Take second snapshot at a later point in time pfexec zfs snapshot -r rp...@second # Send the increments to the backup pool pfexec zfs send -i rpool/r...@first rpool/r...@second | pfexec zfs recv -F backup-pool/rpool/ROOT pfexec zfs send -i rpool/ROOT/opensolaris-2009.06-...@first rpool/ROOT/opensolaris-2009.06-...@second | pfexec zfs recv -F backup-pool/rpool/ROOT/OpenSolaris-2009.06-134 pfexec zfs send -i rp...@first rp...@second | pfexec zfs recv -F backup-pool/rpool pfexec zfs send -i rpool/d...@first rpool/d...@second | pfexec zfs recv -F backup-pool/rpool/dump pfexec zfs send -i rpool/s...@first rpool/s...@second | pfexec zfs recv -F backup-pool/rpool/swap pfexec zfs send -i rpool/websp...@first rpool/websp...@second | pfexec zfs recv -F backup-pool/rpool/webspace pfexec zfs send -i rpool/exp...@first rpool/exp...@second | pfexec zfs recv -F backup-pool/rpool/export pfexec zfs send -i rpool/export/h...@first rpool/export/h...@second | pfexec zfs recv -F backup-pool/rpool/export/home pfexec zfs send -i rpool/export/home/e...@first rpool/export/home/e...@second | pfexec zfs recv -F backup-pool/rpool/export/home/euan pfexec zfs send -i rpool/export/home/e...@first rpool/export/home/e...@second | pfexec zfs recv -F backup-pool/rpool/export/home/euan/Downloads pfexec zfs send -i rpool/export/home/euan/vbox-...@first rpool/export/home/euan/vbox-...@second | pfexec zfs recv -F backup-pool/rpool/export/home/euan/VBOX-HDD pfexec zfs send -i rpool/export/home/euan/downlo...@first rpool/export/home/euan/downlo...@second | pfexec zfs recv -F backup-pool/rpool/export/home/euan/Downloads #pfexec zfs umount backup-pool/rpool/export/home/euan/VBOX-HDD #pfexec zfs umount backup-pool/rpool/export/home/euan/Downloads #pfexec zfs umount backup-pool/rpool/export/home/euan #pfexec zfs umoun
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Thanks Edward, you understood me perfectly. Your suggestion sounds very promising. I like the idea of letting the installation CD set everything up, that way some hardware/drivers could possibly be updated and yet it still work. On top of a bare metal recovery, I would like to leverage the incredible power of ZFS snapshots, I love the way zfs send / receive works. It's the root pool and BEs complexities that worry me. My ideal solution would be to have the data accessible from the backup media (external HDD) as well as be used as full syatem restore. Below is what I would consider ideal: 1.) Create a pool on an external HDD called backup-pool 2.) Send the whole rpool (all filesystems within) to the backup pool. 3.) be able to browse the backup pool starting from /backup-pool 4.) be able to export the backup pool and import on PC2 to browse the files there 5.) be able to create another snapshot of rpool and "zfs snapshot -i rp...@first-snapshot rp...@next-snapshot backup-pool/rpool" (send the increment to the backup pool/drive 6.) be able to browse the latest snapshot data on the backup drive, whilst able to clone an older snapsho 7.) be able to 'zfs send' the latest backup snapshot to a fresh installation, thus get it back to exactly how it was before disaster. At the moment I have successfully achieved 1-4 and I'm very impressed. I am currently trying to get 5-6 working, mildy confident that it will work, done it in part but got errors with /export/home filesystem and subsequently pool failed to import/export. It's just copying over again after wiping backup pool and starting again. I hope build 134 is a good build to test this on. However, it's step 7 that I have no idea if it will work. Edward, your post gives me promise, 90% confidence is a good start. Watch this space for my results. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Thanks Cindy for the links. I see that this could possibly be a replacement for ufsbackup/ufsrestore but unless a further snapshot can be appended to the file containing the recursive rootpool snapshot, it would still regress from the incremental backup that ufsbackup has. It would take a long time to run every night but on the plus side an in-situe backup without having to stop services is an improvement from UFS days. Haven't tried it yet, sounds a bit more complicated than I had hoped for. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Cindy Swearingen > > For full root pool recovery see the ZFS Administration Guide, here: > > http://docs.sun.com/app/docs/doc/819-5461/ghzvz?l=en&a=view > > Recovering the ZFS Root Pool or Root Pool Snapshots Unless I misunderstand, I think the intent of the OP question is how to do bare metal recovery after some catastrophic failure. In this situation, recovery is much more complex than what the ZFS Admin Guide says above. You would need to boot from CD, and partition and format the disk, then create a pool, and create a filesystem, and "zfs send | zfs receive" into that filesystem, and finally install the boot blocks. Only some of these steps are described in the ZFS Admin Guide, because simply expanding the rpool is a fundamentally easier thing to do. Even though I think I could do that ... I don't have a lot of confidence in it, and I can certainly imagine some pesky little detail being a problem. This is why I suggested the technique of: Reinstall the OS just like you did when you first built your machine, before the catastrophy. It doesn't even matter if you make the same selections you made before (IP address, package selection, authentication method, etc) as long as you're choosing to partition and install the bootloader like you did before. This way, you're sure the partitions, format, pool, filesystem, and bootloader are all configured properly. Then boot from CD again, and "zfs send | zfs receive" to overwrite your existing rpool. And as far as I know, that will take care of everything. But I only feel like 90% confident that would work. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
Hi Euan, For full root pool recovery see the ZFS Administration Guide, here: http://docs.sun.com/app/docs/doc/819-5461/ghzvz?l=en&a=view Recovering the ZFS Root Pool or Root Pool Snapshots Additional scenarios and details are provided in the ZFS troubleshooting wiki. The link is here but the site is not responding at the moment: http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide Check back here later today. Thanks, Cindy On 04/28/10 23:02, Euan Thoms wrote: I'm looking for a way to backup my entire system, the rpool zfs pool to an external HDD so that it can be recovered in full if the internal HDD fails. Previously with Solaris 10 using UFS I would use ufsdump and ufsrestore, which worked so well, I was very confident with it. Now ZFS doesn't have an exact replacement of this so I need to find a best practice to replace it. I'm guessing that I can format the external HDD as a pool called 'backup' and "zfs send -R ... | zfs receive ..." to it. What I'm not sure about is how to restore. Back in the days of UFS, I would boot of the Solaris 10 CD in single user mode command prompt, partition HDD with correct slices, format it, mount it and ufsrestore the entire filesystem. With zfs, I don't know what I'm doing. Can I just make a pool called rpool and zfs send/receive it back? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Best practice for full stystem backup - equivelent of ufsdump/ufsrestore
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Euan Thoms > > I'm looking for a way to backup my entire system, the rpool zfs pool to > an external HDD so that it can be recovered in full if the internal HDD > fails. Previously with Solaris 10 using UFS I would use ufsdump and > ufsrestore, which worked so well, I was very confident with it. Now ZFS > doesn't have an exact replacement of this so I need to find a best > practice to replace it. > > I'm guessing that I can format the external HDD as a pool called > 'backup' and "zfs send -R ... | zfs receive ..." to it. What I'm not > sure about is how to restore. Back in the days of UFS, I would boot of > the Solaris 10 CD in single user mode command prompt, partition HDD > with correct slices, format it, mount it and ufsrestore the entire > filesystem. With zfs, I don't know what I'm doing. Can I just make a > pool called rpool and zfs send/receive it back? An excellent question. One which many people would never bother to explore, but important nonethenless. I have not tested this, so I'll encourage testing it and coming back to say how it went: I would install solaris or opensolaris just as you did the first time. That way, the bootloader, partition tables, etc, are all configured for you automatically. (Just restoring the filesystem is not enough.) Then I'd boot from the CD, and zfs send | zfs receive, from the external backup disk to the actual rpool. Thus replacing the entire filesystem. You should test this, because I am only like 90% certain it will work. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
