BUILD Designing a server for cold storage, low availability?

[cyberjock]

Ok.. well, strictly as a backup server.. I'd run it 24x7, do automated ZFS replication to it daily, hourly, whatever floats your boat, and be happy. Skip the tapes.

 

[nanodec]

I agree with cyberjock's statement. Considering the inexpensive nature of PC hardware nowadays, run it 24x7 and not worry about it. Heck, the PC I'm using right now for my box is an older HP Z800 workstation that we were getting rid of at work. Granted, it's not the most power efficient thing on the market that you could build but for me it gets the job done. All I did for "upgrades" to it was drop another 8GB of RAM in it to bring it up to 16, and yanked/replaced the OS drive in it for my zpool I was carrying over from my older box. I added a new 16GB USB drive to the mix for the OS, installed it and went about my merry way.

I pretty much reboot mine one a month usually, mostly to apply any critical updates that come out that look interesting. Other then that, I have an off-site backup of everything and will run this thing till the fans quit. At that point, I may change out the fans or pull the pool and migrate it to a newer box... dunno yet.

For you, build it, run it 24x7 till it's toast, then rinse and repeat.

 

[Bidule0hm]

it won't be fixed until the server is brought back online and then scrubed.

Not true. It's also fixed when your read the data ;)

 

[maglin]

Not true. It's also fixed when your read the data ;)

True and fixed. My knowledge of ZFS and FreeNAS is growing exponentially as I read more issues and best practices.

 

[star]

What's the best way to transfer this data stored on SATA drives on a Windows box? Pop it into the FreeNAS server and copy it to a burned in drive?

And how do you guys feel about used drives from ebay? :)

 

[Ericloewe]

What's the best way to transfer this data stored on SATA drives on a Windows box? Pop it into the FreeNAS server and copy it to a burned in drive?

Network, I'm afraid.

NTFS can be imported in a pinch, but it's typically not worth the hassle.

 

[Robert Smith]

Yeh, convenience wise…

Since it is only about what 2 TB you need to transfer? Make a ROBOCOPY script, and let it run. The subsequent incremental backups should go much faster; unless you use something like large encrypted file containers that need to be copied as a whole every time something changes (in that case keep the containers on the NAS, instead of copying them from the local box every time).

 

[star]

Yeh, convenience wise…

Since it is only about what 2 TB you need to transfer? Make a ROBOCOPY script, and let it run. The subsequent incremental backups should go much faster; unless you use something like large encrypted file containers that need to be copied as a whole every time something changes (in that case keep the containers on the NAS, instead of copying them from the local box every time).

Yeah, nothing fancy, just pictures and video sitting on a NTFS drive owned by a Windows 8 computer. Could I just do NIC to NIC with a crossover cable?

Will ROBOCOPY do incremental backups, or will that be handled by the FreeNAS server? Is there a piece of software I should look into for making these backups smoother? Some sort of client-side error checking I can do? I've been using SyncToy for a long time and I am going to miss its functionality when I offload the backup job from my PC to this server.

 

[pirateghost]

Yeah, nothing fancy, just pictures and video sitting on a NTFS drive owned by a Windows 8 computer. Could I just do NIC to NIC with a crossover cable?

Will ROBOCOPY do incremental backups, or will that be handled by the FreeNAS server? Is there a piece of software I should look into for making these backups smoother? Some sort of client-side error checking I can do? I've been using SyncToy for a long time and I am going to miss its functionality when I offload the backup job from my PC to this server.

I'm confused on what you are asking.

What purpose do you have to do incremental after your initial seeding of the data to be moved to the nas?

Is it for backups? You can continue to use synctoy if you like. I prefer delta copy and rsync jobs, some people prefer urbackup.

I guess you need to be clear on the end goal rather than asking a vague question about incremental backups. Incremental to what?

 

[star]

I'm confused on what you are asking.

What purpose do you have to do incremental after your initial seeding of the data to be moved to the nas?

Is it for backups? You can continue to use synctoy if you like. I prefer delta copy and rsync jobs, some people prefer urbackup.

I guess you need to be clear on the end goal rather than asking a vague question about incremental backups. Incremental to what?

Sorry for being vague.

To be clear, the majority of my backup data consists of pictures and video (around 2TB) that is high priority. I don't expect these files to change once seeded.

I also have around 200GB of documents that I would like to keep backed up every week/month to this backup server. I'm trying to figure out the best workflow for backing up to this data from a Windows machine to the FreeNAS server.

Any recommendations on this workflow are greatly appreciated!

I'm about to pull the trigger on the following hardware, just need help figuring out a decent quiet PSU:

• Case: Thermalbake Oppressor F-51 = $119
• Disks: (3) HGST Deathstar NAS H3IKNAS30003272SN (0S03660) 3TB 7200 = $372
  
  • OS drive: Spare SSD
• Mobo: (1) ASSRock C2550D4I Mini ITX = $299
• Memory: TBD, depends if we have any of the recommended dimms for the ASSRock lying around
• PSU: ???

 

[pirateghost]

Like I said, you can keep using synctoy, nothing stops you from that, and honestly you probably don't have to change your workflow much to accommodate. Just the path in which the backups reside.

I prefer to use rsync, and on windows combine it with delta copy.

I will be giving urbackup a shot in the coming days.

 

[star]

Cool. I'm pretty much ready to buy if anyone has suggestions on a quiet, modular PSU!

 

[Robert Trevellyan]

Cool. I'm pretty much ready to buy if anyone has suggestions on a quiet, modular PSU!

I speak not from experience or knowledge but merely from seeing the same thing repeated over and over in the forums: SeaSonic.

 

[star]

I speak not from experience or knowledge but merely from seeing the same thing repeated over and over in the forums: SeaSonic.

One thing I've read is that some of these ~500W PSUs don't handle low power loads very well. Is there a PSU out there that would be more appropriate for 200-300W (max)?

 

[Ericloewe]

Cool. I'm pretty much ready to buy if anyone has suggestions on a quiet, modular PSU!

In ATX format?

Seasonic G-450, X-650/Platinum 650 if you want full modularity.

 

[Ericloewe]

One thing I've read is that some of these ~500W PSUs don't handle low power loads very well. Is there a PSU out there that would be more appropriate for 200-300W (max)?

Not a problem with anything remotely modern.

 

[DataKeeper]

Just to add after reading through the thread...

1. WD RED NAS drives would be a better drive then the HGST drives for your application. The REDs require less power, run quieter and also cooler then the HGST.
2. Also, either add a second SSD drive OR use 2x thumb drives like the Cruzer FIT 32G and mirror them!

 

[Robert Smith]

Yeah, nothing fancy, just pictures and video sitting on a NTFS drive owned by a Windows 8 computer. Could I just do NIC to NIC with a crossover cable?

Will ROBOCOPY do incremental backups, or will that be handled by the FreeNAS server? Is there a piece of software I should look into for making these backups smoother? Some sort of client-side error checking I can do? I've been using SyncToy for a long time and I am going to miss its functionality when I offload the backup job from my PC to this server.

Most modern NICs have cross-talk auto detection, so you can just use a straight cable, but yes a crossover cable will definitely work.

There are tons of different backup/synchronization software packages; ROBOCOPY is convenient because modern versions of Windows include it out of the box, no need to install anything extra.

For example, make a following batch file (backup_my_files_to_nas.bat):

Code:

NET USE \\FreeNAS\sharename pa$$word /USER:FreeNAS\username
ROBOCOPY "C:\MyPictures" "\\FreeNAS\sharename\MyPictures" /MIR /ZB /DCOPY:T /FFT /tee /log+:%AppData%\robocopylog.txt
ROBOCOPY "C:\MyVideos" "\\FreeNAS\sharename\MyVideos" /MIR /ZB /DCOPY:T /FFT /tee /log+:%AppData%\robocopylog.txt

And it will copy MyPictures and MyVideos folders, and all their contents, to the sharemane SAMBA share on the FreeNAS. Run that batch file again, and it will copy new/changed files, it will also delete files on the NAS you deleted locally. There are many different ROBOCOPY options to adjust the behavior.

You can also run the batch file automatically through Task Scheduler.

ROBOCOPY can be destructive, so study it before you running on important data.

 

[Robert Smith]

And, as it has been already said, nothing is stopping you from continuing using SyncToy, if that is what you like.

When you use NAS like this, you have to realize that if a file gets corrupted (or cryptolocked) on your workstation, the next synchronization may override a good file on NAS with a corrupted file from the local computer.

One way to soften the blow is to configure automatic snapshots on the FreeNAS, and save those snapshots for long time [forever maybe?]. If you notice a corrupted file, and you still have the snapshots dating back to when the file was good, you can restore the file from the snapshot.

 

[Ericloewe]

Most modern NICs

It's part of the GbE specification, in fact. Even the ultra-crummy Realteks support it.

One way to soften the blow is to configure automatic snapshots on the FreeNAS, and save those snapshots for long time [forever maybe?]. If you notice a corrupted file, and you still have the snapshots dating back to when the file was good, you can restore the file from the snapshot.

Just to clarify, this applies to User-induced (real user, malware, whatever...) changes, as opposed to corruption at the ZFS level. There's no good way to recover from the latter case.