Replicate - Reconfigure - Replicate back?

[Z300M]

Using

zfs send ... | zfs receive ...

I have replicated Pool1 to Pool2/Replicas, intending to destroy the current Pool1 (2 x 6-drive RAIDZ2 pools), recreate Pool1 as a single 11-drive RAIDZ3 pool, then use

zfs send ... | zfs receive ...

to replicate everything back from Pool2/Replicas to Pool1/.

However, under Pool2/Replicas I see not only the desired datasets (the same as those that exist on Pool1) but also

/.system/* and /.warden-template-*

How do I exclude these unwanted datasets?

 

[Z300M]

Or do I just destroy those unwanted datasets under Pool2/Replicas first?

 

[Bidule0hm]

One of my rules for backups is "backups are read-only, don't touch it, copy it and make changes to the copy", well, ok, I'm a bit paranoid, but as the other guy says "Only the paranoid survive" :)

 

[Z300M]

One of my rules for backups is "backups are read-only, don't touch it, copy it and make changes to the copy", well, ok, I'm a bit paranoid, but as the other guy says "Only the paranoid survive" :)

OK, so I just let all those .system/* and .warden-template-* datasets get copied back to the root of Pool1? What if datasets with those same names exist already in the root of the newly recreated Pool1? Or will they not exist already?

 

[Bidule0hm]

I'd rename them until I'm sure I don't need them and then delete them ;)

 

[Robert Trevellyan]

How do I exclude these unwanted datasets?

Are there too many to replicate the ones you want back to Pool1 one at a time?

 

[Ericloewe]

Replicating the .system dataset used to have nasty consequences. I'm not sure they've prevented the replication from happening, but they were going to do it.

The only "correct" method I know of is to only replicate the lower level datasets that you want, instead of the top level dataset.

 

[Z300M]

I'd rename them until I'm sure I don't need them and then delete them ;)

If there's a way of renaming a dataset (at least, from the GUI), I haven't found it. And if I go to the console, the .system directory does not seem to show up at all.

 

[Z300M]

Replicating the .system dataset used to have nasty consequences. I'm not sure they've prevented the replication from happening, but they were going to do it.

The only "correct" method I know of is to only replicate the lower level datasets that you want, instead of the top level dataset.

Or, now that I have replicated everything, is there any downside to simply destroying the .system/* and/or .warden-template-* datasets before I replicate back to the reconfigured Pool1?

 

[Robert Trevellyan]

Or, now that I have replicated everything, is there any downside to simply destroying the .system/* and/or .warden-template-* datasets before I replicate back to the reconfigured Pool1?

I suggest verifying where the .system dataset is right now before destroying that one. Assuming FreeNAS isn't using the one on Pool2 see no harm in destroying it. On the contrary, it seems like a good idea. I would assume the same for the .warden-template* dataset too, i.e. if it isn't in use, destroying it is probably a good idea.

However, if you then replicate the entire top level dataset back to Pool1, you will risk destroying the active .system dataset, so you may still need to replicate the individual datasets back to Pool1 to prevent that.

A possible workaround would be to add another single-disk volume temporarily and tell FreeNAS to put the .system dataset on it. FreeNAS will automatically move the existing .system dataset to the new location. Then you could try replicating everything back in one go, then reassigning .system to Pool1, then detaching the single-disk volume.

 

[Z300M]

I suggest verifying where the .system dataset is right now before destroying that one. Assuming FreeNAS isn't using the one on Pool2 see no harm in destroying it. On the contrary, it seems like a good idea. I would assume the same for the .warden-template* dataset too, i.e. if it isn't in use, destroying it is probably a good idea.

However, if you then replicate the entire top level dataset back to Pool1, you will risk destroying the active .system dataset, so you may still need to replicate the individual datasets back to Pool1 to prevent that.

A possible workaround would be to add another single-disk volume temporarily and tell FreeNAS to put the .system dataset on it. FreeNAS will automatically move the existing .system dataset to the new location. Then you could try replicating everything back in one go, then reassigning .system to Pool1, then detaching the single-disk volume.

The current .system dataset is on Pool1. Would an 8GB thumb drive suffice as the temporary parking place for the .system dataset? If not, I do have a spare HDD that I could use.

Would it be a good idea to detach both pools before shutting down, first marking as new the existing Pool1 (the one that is to be reconfigured) but not deleting the share's configuration. Then, after rebooting,

1. create the new Pool1

2. move the .system dataset to the new Pool1

3. reattach Pool2

4. delete the .system/* and/or .warden-template-* datasets from Pool2/Replicas

5. replicate Pool2/Replicas back to Pool1

Any problem with that?

 

[Robert Trevellyan]

Don't detach Pool 2 until the whole process is complete.

I'm pretty sure your step 5 will stomp on the .system dataset on Pool1 if the replication target is at the top level. I think it would be better to have .system elsewhere during the whole process. Come to think of it, there's no reason you can't tell FreeNAS to put .system on Pool2 for now. It will go to the top level, so no conflict with the one in Pool2/Replicas (which you'll be destroying). After replicating back to Pool1, move .system back there.

You might not be able to preserve your shares during this process. I think you'll get a warning at least, when you destroy Pool1. At minimum I would shut down the services for the share types you're using.

 

[Robert Trevellyan]

Under the circumstances, you might want to practice the process in a VM before doing it for real.

 

[Z300M]

Under the circumstances, you might want to practice the process in a VM before doing it for real.

What if I move the .system dataset to that temporary storage, destroy the whole of Pool2/Replicas, then re-execute the original zfs send... | zfs receive... to the root of Pool2, then move the .system dataset to Pool2, then blow away and reconfigure Pool1 (or whatever its new name will be). Pool2 will then be the new "master" pool, with the new pool as a backup or whatever?

 

[Robert Trevellyan]

Why repeat the whole process? You already have your replica. Or is the current configuration of Pool2 not what you want?

 

[Z300M]

Why repeat the whole process? You already have your replica. Or is the current configuration of Pool2 not what you want?

It's OK except that the contents of Pool1 are under Pool2/Replicas rather than under the root of Pool2.

 

[Robert Trevellyan]

It's OK except that the contents of Pool1 are under Pool2/Replicas rather than under the root of Pool2.

That doesn't matter, you just have to use the right flags on the zfs send and zfs receive commands.

 

[Z300M]

That doesn't matter, you just have to use the right flags on the zfs send and zfs receive commands.

Figuring out "the right flags" is what I have to spend time on.

 

[Robert Trevellyan]

Focus on the last paragraph under the description of zfs receive, especially the part that begins "If the -d or -e option is specified..."