NAS to NAS backup using rysnc failure

---

Ray2 wrote:

I Discovered that the NAS314 folder did not have the NFS protocal turned on. Turned it on. Don't think I changed anything else, and it now works fine. 

 

---

That shouldn't have mattered, but obviously something changed.

---

Ray2 wrote:

I have read some things on here about "pushing" versus "pulling" backups--but I dont remember if one is recommended over other?  

The advantage of "Push" -  The RN628 will create a snapshot of the source, and then it backs up that snapshot.  That ensures that the entire folder is backed up coherently (at the instant the snapshot is created).  If you want to back up the system while you are working, then push is the right option.

The advantage of "Pull" - it makes it possible to put the RN314 on a power schedule.  The RN314 won't power down until the backup is complete.  If you use "push", if the backup takes a bit longer than usual, the RN314 might shut down too early. 

My own backup NAS are on power schedules, so I use "Pull".  The backup jobs are scheduled off-hours, so the fact that coherency isn't guaranteed isn't a problem for me.

---

Ray2 wrote:

should I be using DR method and if so, store them where? 

---

This depends in part on what you want to do if the RN628 were to fail.  If you use rsync, then you can simply switch over to the RN314 while you are rebuilding the RN628.  You can't do that with ReadyDR - the files won't be available until you restore the ReadyDR backup.  Generally that requires bringing the main NAS back on-line (since you likely won't have enough storage to restore them to an RN314 share),

ReadyDR will in most cases transfer less data over the network than Rsync, so that is a consideration in some situations.  It's the most efficient way to back up an iSCSI LUN or a large database.

---

Ray2 wrote:

 

Currenlty I have snapshots turned on the NAS 628 by respective folders; but NOT at all on the 314. Does this make sense or should I be using DR method and if so, store them where?  Your thoughts on best practices greatly appreciate!

 

---

I have custom snapshots set on my backup NAS (most shares have 30 day retention).  Snapshots are only taken if the share contents have changed from the previous snapshot.  The snapshots are daily (as are the backups), and are taken a bit before the backup jobs run.  The rationale here - rsync has no built-in versioning, so there is no way to restore an old version of a file if it is accidentally deleted.  Adding the snapshots gives me the equivalent of versioning.

I have the same snapshot setting on the shares of the main NAS (an RN526 in my case).  So I would ordinarily get older versions on the main NAS, but would preserve that ability if I ever have to rebuild it.

---

Ray2 wrote:

The NAS 628 stores my everyday changing work, and now treating the NAS 314 as a total backup resource along with a USB external which I swap out regularly to store in a safe place.

 

---

That makes a lot of sense, expecially if the USB drive is off-site.  Sandshark has an offsite NAS, and uses ZeroTier as a VPN to allow him to back up offsite easily.  I've used CrashPlan for some years for disaster recovery - it would be slow if I ever needed it, but it is pretty cost effective.  Though I do have a relative not too far away, so I could also switch over to Sandshark's approach.

---

Ray2 wrote:

Your thoughts on best practices greatly appreciate!

---

First, what you are doing now sounds good to me.

Generally I try to think up scenarios where my backup plan would fail, and then figure out if there is a cost-effective way to improve it.  The power schedules do of course save power, but the main reason is that if there is a malware attack, at least one backup NAS will be powered down.  That would give me time to complete the air-gap by disconnecting that NAS from the network.  I also have all file sharing protocols disabled on the backups, in order to reduce the chance that malware could spread directly to the backup NAS.

In your case, the malware protection is the stored USB drive