Backing up to a NAS

My QRecall archive is around 460 GB. Until a few weeks ago I had been backing up to my NAS (an Asustor 606-T) by WiFi. By and large this worked OK BUT the verify process was taking 20+ hours. I have now abandoned WiFi for my desktop computers hard-wiring them, the ADSL modem, NAS etc together. Doing this has cut verification down to around 2 hours AND, thus far at least, cut out the small errors that had crept in during the WiFi backups.

At the same time I have revised my Actions to use a daily 'Rolling Merge' in which I'm keeping the most recent 7 days, followed by 8 day layers, 6 week layers and 12 month layers. Given that I'm not short of space on the NAS, is this a good choice? Indeed is there a recommended suite of Actions when backing up to a NAS?

-- Charles

For equipment that doesn?t wander around, Ethernet is much preferred over WiFi.

As for your merge action and schedule, this is entirely a matter of taste, need, and resources. Your archive isn?t that big, so you?re not constrained by resources—either by your disk space limits or computer time. So the only question is how much information do you want to capture and for how long.

The questions I like to ask are ?How often do my files change?? and ?How long would it be before I notice a problem I?d want to recover from?? Answering those two will questions will guide you on setting up the rolling merge. Here are two additional tips:

- I like to set the ?Ignore? period in the rolling merge to at least 3 to 7 days. This is my fine-grained incremental backup period. By never merging any layers in the past few days, I have access to hourly versions of my files should I discover I?ve done something stupid. And that happens more often than I care to admit.

- If you?ve got plenty of disk space, your merge and compact actions don't need to be performed every day. Schedule them to run once, maybe twice, a week. Schedule the merge to run before the compact.

Overall, it sounds like you?ve got things running pretty smoothly.

Why does it have to be like that anyway?
I mean, why is NAS over WiFi (even 800MBit/s) so excruciatingly slow in comparison with that very same NAS over CAT-5, FW-800 or USB-3.0?

Can we do anything to improve QRecall performance when backing up via WiFi? Maybe downloading some index data just once and using it locally? I would gladly spend a few GiB's on index caches if it meant I'd be able to make my backup runs quicker.

Norbert Karls wrote:? why is NAS over WiFi (even 800MBit/s) so excruciatingly slow in comparison with that very same NAS over CAT-5, FW-800 or USB-3.0?

This is the nature of WiFi. While the raw transmission speeds of the WiFi and Eithernet have gotten remarkably close, the reality is that the two operate in completely different environments. WiFi has to deal with interference, signal strength, collision avoidance (CSMA/CA vs. CSMA/CD), competing WiFi transmitters, and the latency of radio signals. While there are often things you can do to improve your WiFi performance?like switching channels?most of the performance issues are physical limitations of trying to conduct TCP/IP transactions using a radio.

Can we do anything to improve QRecall performance when backing up via WiFi? Maybe downloading some index data just once and using it locally?

I?ve considered local caching of some index files, but most of the indexes are already read once and cached in memory (which is quite fast, even using WiFi). The biggest problem is latency and the random accesses needed to match the data being captured with the data already in the archive. Random access really take a beating (performance wise) when latency is high.

Remember that the merge, compact, and verify actions apply to the archive as a whole and not to the individual computers, so if you're backing up multiple computers to the same archive you can perform those actions from a hard-wired machine even if you're backing up laptops over wifi.

If you back up laptops to separate archives it may still be possible to merge, verify, etc. those archive from a wired computer on the network. I'm not sure about that, though, since I don't do it that way.