Data Migration

[arb]

I'm trying to replace an existing Windows Home Server installation with FreeNAS. I've got a 1.5TB drive in my new server. I have two 1TB drive remaining in the Windows box with all my data on it. I'd like to use all three of these drives in one vdev and one pool. Is there a way to do it without introducing a fourth driving into the mix?

Currently I'm feeling a little like the Towers of Hanoi; if I buy another drive, move all of the data onto that, then I won't be able to include that new drive into the new vdev and would have to make another vdev and have a single drive in a vdev in one pool which seems like a bad idea.

Does the "Import Volume" feature play into this at all?

I do realize I will have to "flatten" the data from the Windows box into regular NTFS before I do anything, but what is my next step after that?

 

[anodos]

I'm trying to replace an existing Windows Home Server installation with FreeNAS. I've got a 1.5TB drive in my new server. I have two 1TB drive remaining in the Windows box with all my data on it. I'd like to use all three of these drives in one vdev and one pool. Is there a way to do it without introducing a fourth driving into the mix?

Currently I'm feeling a little like the Towers of Hanoi; if I buy another drive, move all of the data onto that, then I won't be able to include that new drive into the new vdev and would have to make another vdev and have a single drive in a vdev in one pool which seems like a bad idea.

Does the "Import Volume" feature play into this at all?

I do realize I will have to "flatten" the data from the Windows box into regular NTFS before I do anything, but what is my next step after that?

Post your FreeNAS server's hardware specs.

You could always do the following: copy your data to the 1.5TB drive, create a zpool consisting of a single mirrored VDEV from the 2x 1TB drives, copy your data from the 1.5TB drive to the 1TB drives. At a later date you can expand the size of your pool by adding a second mirrored vdev and striping your data. Just be sure you don't overfill your zpool.

 

[pjc]

No, and you don't particularly want to mix drive sizes in a vdev anyway.

I'm assuming you have ~2TB of data:
1) Get another 1.5TB drive and create a separate 1.5TB pool ("B"), for a total of 3TB ZFS capacity. Do NOT configure your 1.5TB drives as a single striped pool, since then you can't remove the second drive.
2) Copy over your data onto the 3TB of storage (pools "A" and "B"), putting no more than 1TB in one of the pools (e.g. "B").
3) Move over your 2x1TB drives, set them up as a mirrored pair in a new pool with 1TB capacity ("C").
4) Move 1TB from "B" to "C".
5) Get rid of "B" and wipe its 1.5TB drive.
6) Add the now-free 1.5TB drive to pool A as a mirror.
Result: 2.5TB mirrored storage in two pools.

A slightly larger concern is whether you have sufficient hardware to run ZFS, if the cost of a single extra hard drive is prohibitive.

 

[cyberjock]

I'm with pjc. If buying another disk is cost prohibitive that invites speculation that your hardware isn't appropriate for FreeNAS. Most people don't have spare hardware around that is appropriate for FreeNAS. ;)

 

[arb]

I'm not sure what about my question suggested a cost issue? I just don't want to buy things I don't "need." As I said, from my reading, it seemed like only having a single ZPool was the suggested approach I was going to try. I'm really just looking for an approach to move the data and still have a safe ZFS setup on the new server. Sounds like I'll need two zpools, both with a single vdev, which has two drives in it? I'm new to this whole thing so some of my questions may seem really new. And yes, before you ask, I've already read your presentation @cyberjock. Thanks for putting that together :).

I'm still not sure how to actually go about MOVING the data though.

Specs (Not sure what all you need to know but it's plenty to run FreeNas):
Build FreeNAS-9.2.1.8-RELEASE-x64 (e625626)
Platform Intel(R) Atom(TM) CPU C2758 @ 2.40GHz
Memory 16348MB

 

[pjc]

My concern about your hardware is the lack of ECC RAM. (Are you sure you read cyberjock's presentation?) Your clock speed is fine, 16GB RAM is fine.

For moving your data, you can follow the path I articulated above, which will reuse your existing drives and keep redundancy on all your data.

To actually transfer the bits, you can either do it over the network or mount the drive locally, if you have the spare ports. For the former, set up a share, and then use rsync, SMB, etc., whatever is convenient. Just copy from one share to the other. You'll be limited by network speed. For the latter, you attach the drive and import the NTFS volume. I'd probably just log into the server via SSH and to a local copy from NTFS to ZFS, but you could also use rsync locally. That'll be limited by drive speed.

 

[Ericloewe]

My concern about your hardware is the lack of ECC RAM. (Are you sure you read cyberjock's presentation?) Your clock speed is fine, 16GB RAM is fine.

For moving your data, you can follow the path I articulated above, which will reuse your existing drives and keep redundancy on all your data.

To actually transfer the bits, you can either do it over the network or mount the drive locally, if you have the spare ports. For the former, set up a share, and then use rsync, SMB, etc., whatever is convenient. Just copy from one share to the other. You'll be limited by network speed. For the latter, you attach the drive and import the NTFS volume. I'd probably just log into the server via SSH and to a local copy from NTFS to ZFS, but you could also use rsync locally. That'll be limited by drive speed.

How do you conclude he doesn't have ECC? The C2758 supports ECC like all Server-grade Atoms.

 

[anodos]

How do you conclude he doesn't have ECC? The C2758 supports ECC like all Server-grade Atoms.

If someone goes through the trouble of buying a server-grade atom, then odds are he will go through the trouble of buying ecc ram.

 

[pjc]

Open mouth, insert foot. I just saw "Atom" and thought low-end. I didn't realize there were server-grade Atoms with ECC support. So I retract that warning: looks good.