-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum has become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
migrate to new zfs pool
- Thread starter lilarcor
- Start date
Ihave been doing some experiemtn on my end and I think I am on the right track.
You need to have both web gui shown on your system, one pointing to the old and the other to the new system.
Each root account must be given the public key from the other system.
So to begin, go on the old web gui and go to "User accounts" => then select "root" account. Click on the "edit" with th 3 dots ...
THen under the ssh section, you will need to place the key from the new system. To do that, the other web gui must be set to "Tasks" => "Replication Tasks" then click on the button "Replication KEYS". Copy its content and go back to the source web gui where the "rot" account is opened for editing.
Paste the content into the "SSH" section and exit the acount by validaion the action.
Repeat this exact same steps but from the remote system this time.
Once both new and old setups containts each other ssh key, you should be able to proceed with the process.
You need to have both web gui shown on your system, one pointing to the old and the other to the new system.
Each root account must be given the public key from the other system.
So to begin, go on the old web gui and go to "User accounts" => then select "root" account. Click on the "edit" with th 3 dots ...
THen under the ssh section, you will need to place the key from the new system. To do that, the other web gui must be set to "Tasks" => "Replication Tasks" then click on the button "Replication KEYS". Copy its content and go back to the source web gui where the "rot" account is opened for editing.
Paste the content into the "SSH" section and exit the acount by validaion the action.
Repeat this exact same steps but from the remote system this time.
Once both new and old setups containts each other ssh key, you should be able to proceed with the process.
If password is presented to you while doing ssh, it means the key is not recognaized or present on the system you are tying to connect you. Hence following my steps above should clear the issue. At least this is what you need to focus on.
Now both systems can ssh to each other without password. Somehow, the testing returned the same result.
Code:
root@freenas[~]# zfs send -vv -R zfsrz2@a | ssh -i /data/ssh/replication root@192.168.10.179 zfs receive -vv -F zfsrz2 full send of zfsrz2@a estimated size is 12.1K full send of zfsrz2/share@a estimated size is 12.1K full send of zfsrz2/.system@a estimated size is 13.1K full send of zfsrz2/.system/configs-1e6cbdfb415748b98d868947a6e14a88@a estimated size is 12.1K full send of zfsrz2/.system/rrd-1e6cbdfb415748b98d868947a6e14a88@a estimated size is 97.1M full send of zfsrz2/.system/syslog-1e6cbdfb415748b98d868947a6e14a88@a estimated size is 123K full send of zfsrz2/.system/webui@a estimated size is 12.1K full send of zfsrz2/.system/cores@a estimated size is 12.1K full send of zfsrz2/.system/samba4@a estimated size is 1.18M full send of zfsrz2/bak@a estimated size is 12.1K full send of zfsrz2/pdata@a estimated size is 12.1K full send of zfsrz2/pdata/seafile@a estimated size is 12.1K total estimated size is 98.5M root@192.168.10.179's password: TIME SENT SNAPSHOT TIME SENT SNAPSHOT 13:02:43 57.4K zfsrz2/share@a 13:02:44 57.4K zfsrz2/share@a 13:02:45 57.4K zfsrz2/share@a 13:02:46 57.4K zfsrz2/share@a
- Joined
- Aug 19, 2014
- Messages
- 1,111
Well since these systems are on the same local network, there is no need to pipe the zfs send/receive through ssh. Just pipe the zfs send/receive through netcat and alleviate the ssh overhead. Here is a link on how to do it.
Something is really wrong.
Either you haven't set root accounts to hold each others public key or something in the replication process is causing your system to fail.
In you screenshot, I don't see anything related to the transfer for "zfsrz2@a".
192.168.10.179 shouldn't ask you for the password unless the public key and/or fingerprint isn't properly stored.
If you old system is really old, how is it your dataset are only a few KB.
I would suggest you take another recursive snapshot of your entire old pool and call it "b" and try replicating using the following command:
zfs send -vv -R zfsrz2@b | ssh -i /data/ssh/replication root@192.168.10.179 zfs receive -vv -F zfsrz2If you get the same issue, I would suggest to wait a few minutes, as I believe the replication will fail due to a timeout.
When it does, it should return some error of information detailing the cause of the error.
