× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

Re: Backup concurency question

Digital999
Luminary

Backup soncurency question

We have multiple Netgear systems.
Currently there are are a number of backup jobs defined for these systems and they typically occur at off-hours when there is no meaningful traffic. They seem to run.

 

Recently I defined and started several jobs for NAS to NAS backup and NAS to SATA drive backup. Those jobs take literally tens of hours.

 

I observed that jobs created and started manually in the Backup section will not run concurrently -- apparently each job runs sequentially and the other jobs are 'in queue'.

 

If I have a NAS to NAS job running that takes a long time will any of the other backup jobs that are on timers actually run or will they be stalled waiting for the long job to finish?

 

Thanks for any insight

Message 1 of 4

Accepted Solutions
StephenB
Guru

Re: Backup concurency question


@Digital999 wrote:

 

If I have a NAS to NAS job running that takes a long time will any of the other backup jobs that are on timers actually run or will they be stalled waiting for the long job to finish?

 


The scheduled backups are also queued, so they would wouldn't run until the longer job(s) finish.  If they are still running (or waiting to run) when the next scheduled time is reached, then you will get an error message (and the next backup will not be queued, so it won't run twice).

 

If your backups are incremental, then this might still be acceptable.  The long backup times you are seeing now might not be typical.

 

FWIW, my own backups are all NAS-to-NAS, and are run off-hours.  I use "pull" backups (running on the destination NAS), and those will can concurrently, since they are running on different machines. 

 

One drawback of "pull" backups is that you can lose coherency.  When you do a "push" backup (running on the source), the backup is actually being made from a temporary snapshot.  If a file changes during the backup, then you are still guaranteed to get the file as it was at the start of the backup.  But that can't be done with a "pull" backup.

 

One drawback of "push" backups is that it is difficult to put the destination NAS on a power schedule, since you don't know when the backups will end.  That's the reason I use "pull".  

 

 

Another thing you could do is create your own backup scripts for some of the jobs - either running them manually from ssh, or running them as cron jobs.  You'd lose the integration with the web ui, so it'd be more difficult to manage them.  But it is possible.

 

 

View solution in original post

Message 2 of 4

All Replies
StephenB
Guru

Re: Backup concurency question


@Digital999 wrote:

 

If I have a NAS to NAS job running that takes a long time will any of the other backup jobs that are on timers actually run or will they be stalled waiting for the long job to finish?

 


The scheduled backups are also queued, so they would wouldn't run until the longer job(s) finish.  If they are still running (or waiting to run) when the next scheduled time is reached, then you will get an error message (and the next backup will not be queued, so it won't run twice).

 

If your backups are incremental, then this might still be acceptable.  The long backup times you are seeing now might not be typical.

 

FWIW, my own backups are all NAS-to-NAS, and are run off-hours.  I use "pull" backups (running on the destination NAS), and those will can concurrently, since they are running on different machines. 

 

One drawback of "pull" backups is that you can lose coherency.  When you do a "push" backup (running on the source), the backup is actually being made from a temporary snapshot.  If a file changes during the backup, then you are still guaranteed to get the file as it was at the start of the backup.  But that can't be done with a "pull" backup.

 

One drawback of "push" backups is that it is difficult to put the destination NAS on a power schedule, since you don't know when the backups will end.  That's the reason I use "pull".  

 

 

Another thing you could do is create your own backup scripts for some of the jobs - either running them manually from ssh, or running them as cron jobs.  You'd lose the integration with the web ui, so it'd be more difficult to manage them.  But it is possible.

 

 

Message 2 of 4
Digital999
Luminary

Re: Backup concurency question

Thank you again StephenB.

 

Great discussion -- I suspected there was an issue and your answer provided great detail.

 

You may remember we have more that 50 systems nationwide and they are 'managed' by non-technical personnel.  A GUI based interface is almost mandatory.  I will not have anybody mucking around with SSH or cron jobs.  To error prone.

 

We will determine what to do. 

 

BTW,  NETGEAR needs to update their documentation and explain the behavior of the GUI jobs.

 

Thanks for the great answer. 

Message 3 of 4
Sandshark
Sensei

Re: Backup concurency question

If you install ZeroTier on the NAS, you can remotely access it via SSH but don't have to be on the company VPN (if they have one).  You can also use the standard GUI instead of ReadyCloud for administration.  I use ZeroTier exclusively for my remote access -- don't even have ReadyCloud enabled.

 

While quite old, the ReadyNAS-specific version of ZeroTier still works.  Unless you will be on site to use SSH or can remote into a PC on the same network to use for SSH access, you should use the one that still has a GUI (https://github.com/NAStools/zerotierone/releases/tag/readynas%2F1.1.14-nt3 ) so some non-technical local person can set it up.

Message 4 of 4
Top Contributors
Discussion stats
  • 3 replies
  • 1767 views
  • 1 kudo
  • 3 in conversation
Announcements