How resilient is the off site copy for System Recovery

[W_Harrison]

Hi All,

We are using the FTP offsite function with System Recovery and am curious as to how resilient this feature is. In so much as keeping the 'local' and off site files in sync and what happens if there is an interruption in the process?

In our case, Interruptions could be down to an internet failure, vpn tunnel or even a server restart. What mechanics, if any does SR use to check that what's been copied is good. (but more importantly, what does it do if things are 'out', files missing etc.)

What I have noticed is that the Offsite copy can sometimes take a while to actually kick in after an incremental job has finished, I've also noticed that on occasion some of the remote files are actually bigger in size than the original. (we have compare scripts that check file names match as well as sizes).

Thanks

Wayne.

[Markus_Koestler]

Sorry from my side, we do not use this feature.

[akihiro1]

The offsite copy is to synchronize between the primary location and offsite copy location.
So if the offsite copy fails with any reason, System Recovery will try synchronizing again after the next backup job finishes. The success of the offsite copy means the recovery point files in the primary location are completely copied to the offsite copy location.

[W_Harrison]

If I understand this correctly then, SR will check that all files that are on the primary site are copied to the remote site each time a backup is ran, and copy over anything that it sees 'missing' - which is good. Likewise it should also remove any 'extra' files (typically image sets that are removed when they expire when you are only 'keeping' 3 sets).

Following on from that, how detailed is the check? I've seen files that are larger on the remote copy than on the source, will it check against file size matches also or just the existence of a file called the same name? And following on from that, if a file did get interrupted during a copy, then it is also likely that the remote file could be smaller, will it copy the whole file or attempt to see what is 'missing'?

Ultimately is there any hash check against each file to make sure that they are indeed the same?

Thanks again
Wayne.

[akihiro1]

As far as I know, SR checks the hash values between primary location and offsite copy location when offsite copy starts. If the file size is different from the primary location, the file is copied to the offsite copy location.
Also, the file is copied to the offsite copy location when the hash value is different even if the file size is complete the same between primary location and offsite copy location.

Actually I tested this. So the resilience of the offsite copy is strong. 

[W_Harrison]

Thanks for the update...

Has this always been the case for SR? - The reason I ask is that I'm trying to get this to work with a older copy (2013 SR - back in the symantec days) - is this something that was always in place or only has only been introduced in newer versions?

Thanks again.

[akihiro1]

The offsite copy functions are not added or changed except Cloud support or fixes for a part of defects.
That is, I guess that this hash check function will work even on the older versions like Symantec System Recovery 2013 or earlier.

[W_Harrison]

Interestingly, I've been done some testing and from what I've found (and again this is with 2013 SR) - if the destination file size is mismatched (in most cases larger for some reason) then it hasn't re-copied over the file, so not too sure what hash function its doing, if at all. That said, if a file is missing (and I've deleted one that was size mismatched to test) when I then forced an incremental backup, it then copied over the missing file before it went on to copy the new files it had just created.

Would be interesting if there is a developer hiding out there if this is could be confirmed behaviour .

Thanks again.

[akihiro1]

I tested on SR 23. So I recommend to test again on trial version for SR 23. If the files are not synchronized even on SR 23 in your environment, there may be differences between your test steps and my steps.