zpool from 32bit os to 64bit os
the.lists at mgm51.com
Tue Aug 12 15:23:19 UTC 2014
On 8/12/2014 at 9:43 AM Paul Kraus wrote:
|On Aug 12, 2014, at 3:22, Lukasz <lukasz at chroot.pl> wrote:
|> Thank you for answers. I'll try with export/import... I hope my
|> will be safe during this operation. :)
|If you want your data to be really, really safe, then:
0. Make at least one backup of the data before doing anything else,
and make sure the backup worked.
|1. Make sure to export from the original server. While you *can*
|import on the new server, I really, really hate using the force
|the check you are overriding is there for a reason. Sometimes you
|have a choice, but this is not a Disaster Recovery situation (and
|not want it to become one).
|2. When you run the initial `zpool import` on the new system it will
|the zpools it finds *and* their state. If the zpool is not complete
|any way not clean, then DO NOT IMPORT it and put the drives back in
|old system and figure out what is wrong there.
|3. When you run the `zpool import <zpool name || ID>` also set the
|readonly property using the -o option. This way if there is some
|incompatibility (and ZFS does check for this and should want you,
|never really hurts to be paranoid) the new system will not write
|to the zpool.
|4. If the readonly import goes well and all the data is there and
|good, then export the zpool and import it again without the readonly
|property and you should be all set.
|The above may be overkill (depending on what your data is worth :-),
|have seen bugs in ZFS (although not very many in the past few years,
|been using ZFS since about 2007) and the additional time can save
|of time in recovery later on.
|paul at kraus-haus.org
|freebsd-questions at freebsd.org mailing list
|To unsubscribe, send any mail to
|"freebsd-questions-unsubscribe at freebsd.org"
More information about the freebsd-questions