Cost effective Off site backup solution

[DrKK]

C22x will gladly work with non-ECC RAM. X10SAE comes to mind.

The BIOS might be halting if it can't initialize the memory controller in ECC mode, but it seems unusual.

Really?

Are you sure of that? X10SLL and X10SLM's don't even post with non-ECC RAM. The manual even indicates that ECC is required. The X9's would work with non-ECC though

 

[Ericloewe]

Really?

Are you sure of that? X10SLL and X10SLM's don't even post with non-ECC RAM. The manual even indicates that ECC is required. The X9's would work with non-ECC though

Yeah, the X10SAE and the other workstation boards have validated non-ECC RAM.

If the X10SLL+-F/X10SLM+-F/X10SLH-F/X10SL7-F don't boot with non-ECC, it's most likely just incompatible RAM (think Kingston), due to signal tolerances or something.

 

[DrKK]

Ah, the WORKSTATION boards. Never have touched one of those. Thanks for the info.

 

[sremick]

I backup my home freenas server to Amazon glacier. Can't beat the price $0.007/GB per month.

I've looked at this but that amounts to >$50/mo for me, which isn't worth it for this data.

I might look into Crashplan... I hear it's painfully slow, however, and the native FreeNAS plugin seems temperamental.

 

[nojohnny101]

Just wanted to report back and let everyone know the setup that I ended up going with. I waited for some good deals on newegg. I plan on just doing a straight rsync from main freenas box to the backup freenas box that I'm building which will be located offsite.

- Fractal Node 804
- Intel Pentium G3258 Haswell (3.2Ghz)
- ASRock C226M WS
- Seasonic SSR-550RM
- Kingston 8gb x 1 unbuffered 1600MHz DDR3 ECC RAM
- Seagate NAS 3TB x 4
- SanDisk Cruzer Fit CZ33 16GB (for FreeNAS install)

Thanks guys for your ideas and suggestions!

 

[Ericloewe]

There's no good reason to use rsync over ZFS replication if you're using FreeNAS on both ends.

 

[nojohnny101]

@Ericloewe Oh, I guess I am confused a bit. I thought rsync was just a protocol that was intelligent about syncing on the parts of files that have changed. ZFS replication also does this?

 

[Ericloewe]

I thought rsync was just a protocol that was intelligent about syncing on the parts of files that have changed

Not at all. It only works with whole files and it chews up an immense amount of CPU time. ZFS replication works at the block level and doesn't need to check the whole filesystem just to see what's changed - it just sends snapshots and is therefore more efficient.

 

[nojohnny101]

@Ericloewe gotcha. That's strange because I thought I read numerous articles touting how great rsync was when initially researching freenas. I'll have to go back and reread it seems.

Sounds like replication would be the way to go. Just a quick question though, would setting up replication be the same as setting up the main freenas box to save its snapshots to the backup freenas machine? Your use of the word "snapshot" has me a bit confused.

 

[Ericloewe]

Just a quick question though, would setting up replication be the same as setting up the main freenas box to save its snapshots to the backup freenas machine?

You could put it that way.

ZFS replication replicates snapshots of a local ZFS pool on a remote ZFS pool.

That's strange because I thought I read numerous articles touring how great rsync was when initially researching freenas.

Rsync is nice for widespread compatibility, but it's limited by traditional filesystems.

 

[nojohnny101]

ok then. I'll just go with direct ZFS replication, sounds a little easier. Thanks for the help. I'll be building the backup next week, I'll do the first replication on the LAN then move it offsite and report back!

 

[Ericloewe]

That's pretty much what I'll be doing soon (hopefully). Damned new server has been a pain (trailblazing FTW), derailing my neatly laid-out schedule.

At least one of the problems (what if my 10Mb/s upload isn't enough to replicate a day's worth of changes in the allotted time?) is probably going to solve itself soon, with my ISP currently engaged in a bandwidth war with their competition. First they offered 100Mb/s symmetric connections as a promotional deal. Then they upgraded the initial lucky customers to 200Mb/s symmetric and extended the promotional period and added some more deals for both 100Mb/s and 200Mb/s symmetric connections.

 

[nojohnny101]

you lucky dog. wish that was the same case in my area. we have a monopoly here. wheeler should have went farther with title II and capped rates in areas of monopoly. i'm all for free market where there is competition!

you could just turn off snapshots temporarily when the transfer is ongoing right? that is what i plan on doing so things don't get mucked up. I will be cutting it close with my speeds.

 

[Ericloewe]

you could just turn off snapshots temporarily when the transfer is ongoing right? that is what i plan on doing so things don't get mucked up. I will be cutting it close with my speeds.

IIRC, it'll just keep going and immediately start the next one if the previous snapshot took longer to finish than the snapshot period.

Nastiness does tend to happen if you clog the replication pipe with too many snapshots, so don't overdo the changes, if you don't want to sneakernet your server around once in a while to clear the backlog.

 

[nojohnny101]

IIRC, it'll just keep going and immediately start the next one if the previous snapshot took longer to finish than the snapshot period.

gotcha.

i think i'll be find without having to resort to snearknetting. lol, my pool isn't that large and thankfully my internet speeds are abysmal.

 

[Robert Trevellyan]

It only works with whole files and it chews up an immense amount of CPU time. ZFS replication works at the block level and doesn't need to check the whole filesystem just to see what's changed - it just sends snapshots and is therefore more efficient.

I think this could use some qualification.

rsync transfers only the changed parts of existing files. It can even use other files as the basis for partial transfer of new files in the right circumstances. Perhaps when you said "only works with whole files" you meant "in contrast to working at the block level". Definitely room for confusion.

Regarding CPU time, rsync is certainly designed to trade CPU time for bandwidth consumed. It was invented when the original author was using a dial-up modem. Whether what it consumes is "immense" is somewhat subjective. When I see it working hard, it tends to use between 20% and 30% of one core. I've seen it closer to 50% at times.

In the context of FreeNAS ...

• I consider the biggest benefit of rsync to be that it can resume an interrupted transfer, where ZFS replication must start over.
• I consider the biggest benefit of ZFS replication to be that it preserves the whole filesystem structure, including nested datasets and their properties. rsync doesn't know anything about datasets.

I agree that with two FreeNAS boxes, ZFS replication is indicated, but rsync should be given its due credit.

 

[Robert Trevellyan]

I read numerous articles touring how great rsync was when initially researching freenas.

rsync is great, for certain tasks. For example, it's a great way to backup non-ZFS systems to FreeNAS.

 

[johnnychicago]

I am currently trying to figure out how to backup my freenas with the offsite backup machine keeping snapshots older than the ones on my local freenas box, and it seems to me that zfs replication is not what I want. Maybe rsync is.

Properly setup, I cannot currently see what would be bad with a file level transmission. The backup freenas box will then be able to run its snapshot strategy as I see fit on that end. Independently of the local one.

But then, I haven't tried it yet. :)