それ、レプリケーションでよろしく。UDPともども。

タスク1で RPS にバックアップ
タスク2で RPS から別の RPS にレプリケート

このように RPS にバックアップ データをレプリケートすることは、バックアップ データの冗長化という意味でよく使われる構成です。

では、このバックアップ プランの場合、先にお話した「マージ処理」はどの時点で実行されるでしょうか？

正解は タスク２のレプリケートが正常に完了してから になります。

上記の図の右端の RPS へのレプリケート タスクが完了した時点で、全ての RPS 上でマージ処理が実行されます。
つまり、バックアップ プラン内のタスクが全て完了しないとマージ処理は実行されません。
もし各タスクが完了するたびにマージ処理を行ってしまうと、万が一後続のタスクが失敗した場合に各 RPS 間で持っているバックアップ データの整合性が保てなくなるからです。

レプリケート先の RPS を停止してランサムウェア対策。その注意点は？

昨今、ランサムウェアが猛威を振るっているニュースをよく耳にしますが、Arcserve UDP のレプリケート機能を使って手軽にランサムウェア対策をすることができます。

例えば、下記図では、一番右端の RPS は毎月1回だけ起動し、タスク2でレプリケートデータを受け取ったらシャットダウンしています。
RPS をオフラインにしておけば、仮に1台目の RPS 上のデータが暗号化されたとしても、右端の RPS のデータは守られます。

ただし、この方式でランサムウェア対策を検討されている場合はいくつか注意事項があります。

まず、データストア（バックアップ先）の空き容量に注意が必要です。
先にお話したマージ処理、これはバックアップ プラン内のタスクが全て正常完了しないと実行されません。
しかし、上の図の例では1カ月間右端の RPS サーバがシャットダウンしているおり、その間はタスク2のレプリケートが完了しません。
そのため、その手前の RPS ではマージ処理が実行されず、増分バックアップ データが日々溜まり続けることになります。

この増分データが微々たるサイズであれば問題ありませんが、日々の変更データが多い場合には、増分バックアップ データも大きくなります。
これが続くことにより、バックアップ先がパンクしてしまうということも考えられます。

以上のことから、このようなランサムウェア対策を検討する場合は、バックアップ先容量に十分余裕を持った構成をご検討ください。
データストアの設定で「デスティネーションの容量が上限に近づくと、電子メール アラートを送信する」という設定を有効にしておくと、容量がひっ迫する前に気付くこともできます。

（参考）
Arcserve UDP：バックアップが失敗する前に容量不足を知らせてほしい！（復旧ポイント サーバ編）

なお、溜まり続けた増分バックアップ データは、シャットダウンしていた RPS を起動し、タスク2のレプリケート タスクが完了した時点で、全ての RPS 上でまとめてマージされます。

また、レプリケート先の RPS がオフライン中は、レプリケート タスクの転送先が見つからない為、以下のようなエラーが出力します。

そのため、レプリケート ジョブとノード ステータスが失敗の表示になることをご留意ください。
なお、レプリケート先 RPS がシャットダウン中であれば、これらのエラーは無視して頂いて問題ありません。

以上です