Backup to local USB HDD?

[Thund3rDuck]

Hello all,

I am still having a hard time finding an exact answer on how to backup my FreeNAS box to a local USB Drive. I have posed the question before (https://forums.freenas.org/index.php?threads/backup-dataset-to-usb-hdd-local.16013/) and got some really helpful info but no solid solution. I need a simple but proper DR solution to backup/restore the box before I can put it in production in my home.

I don't have the resources to build a separate FreeNAS box at this time. I would like to be able to take a weekly full backup and daily incrementals with a month retention. I would also like to be able to take a drive to an offsite location in case of theft, flood, fire, etc. Please help me in hashing this out to completion.

I would like to use the usb ports on the box vs using another box with a 3rd Party program to sync the shares. Also because the local USB ports would be far faster then sending everything to another machine, with a usb drive connected, over the network.

The current machine I am working with is an older HP Microserver with 8GB of RAM (N45L I think.) It was free so I'm not complaining. I would like to create CIFS/SMB shares and populate the data but have a scheduled FULL backup on Sunday and INCREMENTALS (hourly would be nice, but once a day is fine) Monday through Saturday. At that point I'd like to be notified when the backup finished and if it was successful. Then I can switch out the drives for the next week etc. I would also like these drives to be ENCRYPTED.

If I'm wrong in my thought process here then please enlighten me.

 

[nojohnny101]

Do you have a free SATA port?

 

[Thund3rDuck]

Do you have a free SATA port?

No I do not. I'm needing this to strictly work with USB.

 

[gpsguy]

Are you using the ODD and eSATA ports? And, by the way if you are using them, you should be running one of the hacked BIOS', else they are running in an IDE mode (not AHCI).

No I do not.

 

[Robert Trevellyan]

If you're determined to use USB external drives for backup, consider running the backups on a client system. That way you can use an off-the-shelf backup application. Arq Backup is one option.

 

[Arwen]

Well, USB 2 speed can be an issue on older servers for the following reasons;

• USB 2 and below is half-duplex
• USB 2 and below is non-DMA, thus USB 2 speed is a bit CPU speed dependant
  
• Max theoretical is 480Mega bits per second

In reality, USB 2 is probably maxed out at 30Mega bytes per second, (about 300Mbps).
But, if you can live with that, it may be possible.

Here are some caveats for your situation:

Temporarily connected USB drives may work okay, but permanantly connected is not
recomended. It sounds like you want to leave your backup drive connected for 1 week.
Get a full, then 6 days of incrementals before you change it out.

Encryption, while usable in FreeNAS 9.x, is problematic if you don't clearly understand
it's use. There have been issues when people used FreeNAS disk encryption and did not
test and understand it well enough, thus lost data. Just using ZFS on your backup disk
may stop lots of thieves from reading the drive, (but not law enforcement...).​

FreeNAS does not really support MS-Windows compatible file systems, so your backup
would be ZFS, (or UFS???). Not a problem as long as you know and accept that in
advance.​

I run my backups to an external drive, though it's connected via eSATA. It's temporarily
connected for a full backup about once a month. So far works great.

Last, if you are truly rotating backup drives, I suggest a hard shell Seahorse, (made in the USA),
or Pelican case. And if it's a bare drive, (like mine are), add a static protection baggie. Both very
cheap physical insurance against common problems.

 

[joeschmuck]

I honestly don't see an issue with being able to do what you are asking to be done. Your title states that you are a network engineer so you must have some good brain power so that is a real plus. The problem I think you are having is finding time to develop your own script that would automate this process. I currently see this as an easily solved problem and all you would need to to is break the process into small individual steps like this (not all inclusive) and test them out individually before putting them together:

1) Script must run via CRON once a day.
2) If USB drive is present, mount it, otherwise Exit.
3) Copy data I want.
4) Send email that data was copied without issue (hopefully).
5) Did I copy xx days worth of data, if YES then send email stating so.
6) Umount USB drive.
7) Exit.

As previously mentioned, it's not a good idea to leave a USB external drive connected, meaning mounted, to FreeNAS. Problems can occur so by "umount" the drive, it's operationally not connected.

So that is my advice and like I said, I just don't see this being a big deal. If you are not familiar with scripts under FreeBSD then I would suggest you take some time to learn how it's done. I will say this, it's not Linux even though it is similar.

And to your argument about USB is faster than sending data to another machine which would host the USB drive, yes that is true but if you are doing a data transfer at night when no one is using the system, what does it matter? Also you can use pre-built software and make your like a simple one. But if it were me, I'd build a script just to see if I can do it and it worked very reliably.

 

[Robert Trevellyan]

I'd build a script

You might consider it an opportunity to learn some Python, if you're not already familiar with it. I did that when I wanted to script an rsync task and my key takeaway is that Python is the dogs gonads for scripting.

 

[Mirfster]

Python is the dogs gonads for scripting.

Lol, what does that even mean? Can't tell if that is a good or bad thing....

BTW, I like Python. :D

 

[Robert Trevellyan]

It's a good thing.

The colloquial English expression is "it's the dog's bollocks", meaning "it's the best" or "it's excellent". Some might take offense at the last word. Oh well.

 

[joeschmuck]

Hey, if someone comes up with a nice python script, I'm willing to use it. ;)

 

[SFoskett]

If I were doing this, I'd use a cheap client with Gigabit Ethernet and USB 3.0 and back up over the network using rsync or ZFS Send/Receive. That old MicroServer only has USB 2 and as noted, it's going to be slow! You can likely do more over the network than over USB.

The nice thing about rsync or ZFS is that you can do a scripted incremental backup and have it in a readable format on your drives. I do something similar using external hard disk drives, keeping a set in my water/fireproof vault and another locally. I update the "remote" set about once a week.

Frankly, doing an incremental to a remote location would be even better. And assuming your data doesn't change too much, it would be doable over a regular WAN Link.

 

[Stux]

If I were doing this, I'd use a cheap client with Gigabit Ethernet and USB 3.0 and back up over the network using rsync or ZFS Send/Receive. That old MicroServer only has USB 2 and as noted, it's going to be slow! You can likely do more over the network than over USB.

The nice thing about rsync or ZFS is that you can do a scripted incremental backup and have it in a readable format on your drives. I do something similar using external hard disk drives, keeping a set in my water/fireproof vault and another locally. I update the "remote" set about once a week.

Frankly, doing an incremental to a remote location would be even better. And assuming your data doesn't change too much, it would be doable over a regular WAN Link.

That's what I do. I have my primary system rsync to an on-site backup system. I also rsync across a vpn on a nightly basis to an offsite system. If a large change set 'blocks' the offsite backup, I'll bring it in to catchup.

Unfortunately the overhead of determining the change set with rsync had become excessive, so that leads to replacing the rsync based strategy with ZFS incremental replications, which I'm still in the process of implementing. Offsite system is not ZFS.... Yet ;)

 

[SFoskett]

Unfortunately the overhead of determining the change set with rsync had become excessive, so that leads to replacing the rsync based strategy with ZFS incremental replications, which I'm still in the process of implementing. Offsite system is not ZFS.... Yet ;)

I love rsync, but if you've got lots of files it gets slooooooow even if nothing changed. ZFS incremental send is really amazing for this scenario, but of course you're required to run ZFS on both ends then. I'd say that's a small price to pay!

 

[Stux]

Zackly.

 

[BaoNT]

Sorry for revive the thread, it's been few years and I'm actually running into the same scenario. Would anyone care to share the approaches? Thanks much