Transferring data from one FreeNAS rig to another the safe way..

[vvulture]

Hey guys, after some advice.

I'm planning on building a second Freenas rig and copy the data from the first rig onto it.

Any suggestions on how i can make sure that the data is copied without corruption ?
or perhaps a way to compare the copied data is identical to the source once copied ?

Can the Freenas rigs 'talk' to each other and compare hash/MD5 values of all the files as they are copied ?

Thanks guys..

 

[Brentnall]

I've never done it before but would assume it's possible set up a replication task, let it copy the dataset over as normal and then remove the replication task leaving an exact copy of the data on the destination FreeNAS box.

Try it with a small dataset first to see if it has the desired effect.

 

[danb35]

Any suggestions on how i can make sure that the data is copied without corruption ?

ZFS replication.

 

[vvulture]

Awesome... thanks for the suggestions guys. Much appreciated.

 

[vvulture]

Ok Guys,
I've finally had time to spend time on this and i have a couple of questions :

1 - I've setup a replication task on my source machine and the status is telling me that it is sending the destination machine the oldest snapshot first which was created 12 months ago..
After that snapshot is finished, will it go through all the other snapshots one at a time until it has caught up to the latest one ?

2 - Is there a way to check the integrity of the destination data compared to the source data once the replication is complete ?

Thank you

 

[Chris Moore]

Are you just trying to make a copy of the snapshots or do you want to have the data available for sharing to the network like the first NAS?

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[PhilipS]

Ok Guys,
I've finally had time to spend time on this and i have a couple of questions :

1 - I've setup a replication task on my source machine and the status is telling me that it is sending the destination machine the oldest snapshot first which was created 12 months ago..
After that snapshot is finished, will it go through all the other snapshots one at a time until it has caught up to the latest one ?

2 - Is there a way to check the integrity of the destination data compared to the source data once the replication is complete ?

Thank you

1- Yes
2 - Replication is done at the block level, not file level, so everything will be there - EXACTLY the same.

When replication is complete, you will need to turn off the read only flag on the replicated dataset(s) from the shell: zfs inherit readonly your_dataset

 

[vvulture]

Are you just trying to make a copy of the snapshots or do you want to have the data available for sharing to the network like the first NAS?

Sent from my SAMSUNG-SGH-I537 using Tapatalk

Basically i'm wanting to migrate my data to a new Freenas server which has more storage, but i want to make sure the data is copied without any errors.

 

[vvulture]

2 - Replication is done at the block level, not file level, so everything will be there - EXACTLY the same.

Thank you PhilipS, but how do i know for sure that the data has been copied correctly ? Is there a "Read and Compare" process going on in the background as the data is copied ?

 

[Chris Moore]

Basically i'm wanting to migrate my data to a new Freenas server which has more storage

That is the usual reason. I am on my 5th generation of FreeNAS hardware at home.

but i want to make sure the data is copied without any errors

That is what ZFS is all about. Do you think they would do it any other way?
https://www.freebsd.org/doc/handbook/zfs-zfs.html scroll down to 19.4.5.2. Comparing Snapshots

I saw this earlier and didn't comment because other people had already given you the answer. If you don't trust ZFS send and receive (a file system function) you can always use rsync but it is slower.

Also, something I did in the past to speed up the transfer: After creating the new pool on the new server, shut it down, connect the drives from the old server. To do that, I had the two rack chassis sitting on a work bench next to one another with SAS cables running from the old chassis over to the new chassis. Then power up the new system, import the old pool and it is just a copy between local pools which show up as directories under /mnt. That runs at the speed of SAS which was much faster than the 1Gb network I had at the time. I think it would even smash the speed of the 10Gb network I have now.

 

[Elliot Dierksen]

Also, something I did in the past to speed up the transfer: After creating the new pool on the new server, shut it down, connect the drives from the old server.

That is exactly how I migrated things to my most recent (3rd or 4th generation for me, I forget) server version. I moved the drive controller from the old system to the new system, mounted the old pool, and copied it to the new pool. Crusty old Unix guy commands below
cd /mnt/OLD-Pool
find . -print | cpio -pvmdu /mnt/NEW-Pool


 

[Chris Moore]

That is exactly how I migrated things to my most recent (3rd or 4th generation for me, I forget) server version. I moved the drive controller from the old system to the new system, mounted the old pool, and copied it to the new pool. Crusty old Unix guy commands below
cd /mnt/OLD-Pool
find . -print | cpio -pvmdu /mnt/NEW-Pool


It has been two or three years ago, but I think I used scp to get most of the pool and then ran rsync to complete it. I forget what happened, but something interrupted the copy and rsync just felt like the way to fix it.

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[Elliot Dierksen]

That is exactly how I migrated things to my most recent (3rd or 4th generation for me, I forget) server version. I moved the drive controller from the old system to the new system, mounted the old pool, and copied it to the new pool. Crusty old Unix guy commands below
cd /mnt/OLD-Pool
find . -print | cpio -pvmdu /mnt/NEW-Pool


Anal-retentive completeness compels me to mention that if you have additional data sets created in the pool, you should create those data sets (with the same name(s)) in the new pool prior to copying the files. The above commands only copy files, they don't address pool or data set creation.

 

[PhilipS]

Thank you PhilipS, but how do i know for sure that the data has been copied correctly ? Is there a "Read and Compare" process going on in the background as the data is copied ?

I don't know the underlying details of zfs send/receive (which is what the replication process uses) on how it detects errors in the stream. FWIW, I replicate over a WAN link and have streams fail all the time and I haven't lost any data.

You could run an rsync dry run to verify when the replication finishes.

 

[vvulture]

Thank you for all the advice guys. Much appreciated. :)

 

[Bostjan]

I apologise I don’t know the right terms but I know the gist.


ZFS and/replication task doesn’t know or have error detection build in to detect errors while replicating over a wire. But ZFS has metadata of the data - some sort of checksum of the data. It has multiple copies of this metadata and this metadata has a parent and he has a parent and so on. So ZFS can detect data corruption very easily and 100%.

So if data gets corrupted while replicating, ZFS will detect it on the other side.

 

[Bostjan]

If you are using two FreeNASes the replication procedure is described in the docs.

-----------

If replication task doesn’t succeed, it will let you know in the FreeNAS GUI. And the replication task will automatically try until the process is not 100% successful. You don’t need to do anything. Just wait. :)

 

[Chris Moore]

ZFS and/replication task doesn’t know or have error detection build in to detect errors while replicating over a wire. But ZFS has metadata of the data - some sort of checksum of the data. It has multiple copies of this metadata and this metadata has a parent and he has a parent and so on. So ZFS can detect data corruption very easily and 100%.

@vvulture If that is correct, there is no check of the data that was transferred until you run a scrub on the destination pool. That would cause the checksum and data to be scanned for errors and any errors detected would be corrected.

 

[wblock]

Just to add: ZFS replication makes an exact copy. Any other method, like rsync, runs the risk of losing attributes or doing other things that create a not-quite copy. For instance, rsync is prone to copying hard-linked files as separate files. This can make the target use a lot more space than the source. There are a bunch of command-line flags that can be given to make rsync do the right thing, but it's not easy to work out. Use ZFS replication whenever possible. If you have to use something else, carefully compare the copied version to the original.

 

[Bostjan]

any errors detected would be corrected

Errors are not corrected. ZFS can’t correct data it can detect and if available it can copy data from other “drive”.


If data was corrupted during wire transfer, it has been copied to new pool corrupted. If new pool is mirror, it will be copied to both “disks”. But ZFS will detect it and let you know.


If (for instance) on your primary ZFS pool some data gets corrupted, ZFS will detect that and copy it from other “disk” (if you have mirror) where data is still ok.