{"id":5709,"date":"2015-10-27T15:56:57","date_gmt":"2015-10-27T05:56:57","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5709"},"modified":"2018-12-11T12:00:49","modified_gmt":"2018-12-11T02:00:49","slug":"multihost-consistent-backups-in-networker-9","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2015\/10\/27\/multihost-consistent-backups-in-networker-9\/","title":{"rendered":"Multihost consistent backups in NetWorker 9"},"content":{"rendered":"

NetWorker 9 introduces a new action that can be incorporated into workflows, Check Connectivity<\/em>. You can use this prior<\/em> to a backup action to confirm that you have connectivity to a host before starting the backup. Now, you may think this is a little odd, since NetWorker effectively checks connectivity as part of the backup process, but that’s if you’re looking at Check Connectivity<\/em> on a per-host basis. Used optimally, Check Connectivity<\/em> allows you to easily streamline the process of confirming that all<\/em> hosts are available before starting the backup.<\/p>\n

This option is important when we consider multi-host applications and services within environments where it’s actually deemed critical that the backup either run for everything<\/em> or nothing<\/em>. That way you can’t (in theory) capture logically inconsistent backups of the environment \u2013 for example, getting a backup of an application server but not the database that runs in conjunction with it.<\/p>\n

In the example policy below I’ve created a simple workflow that does the following:<\/p>\n