Is anyone using a RPS model they are actually pleased with? an adequate RPS model for Ahsay seems to be it's greatest short falling.

I've been working with Ahsay for 7 years and this is what I have learned about the behaviour of OBS and issues faced with replication.

Issues with OBS presenting challenges to replication

1) Every file backed up with Ahsay OBS has file headers that get modified frequently, thus changing the file modified date / checksum causing them to get replicated in full whenever they are modified.e.g When the CRC check job runs fortnightly it updates a timestamp in the file header with a current timestamp when the last CRC job completed, this triggers a full re-sync

2) There is no dignified way for RPS to Handle Delta Merging.e.g. say you have a 200gb Exchange Database, every time merging is run on this database the entire file needs re-syncing. This could be daily, multiply that by a few hundred cases and you have issues.

Issues with RPS presenting challenges to replication

1) The RPS model has 3 modes. UNSYNC SYNC and LOGGING. The ONLY time your server is up-to-date is when the RPS is in 'LOGGING' mode, that is when it is replaying all changes as they happen to RPS, both UNSYNC and SYNC indicate it is re-syncronising everything, and backlogging the changes on your HOST server, this means if your HOST server suffers any data failure, you have also lost the backlog.

2) Any issues with replication causes your replication to start again from UNSYNC mode, this means that again your replication starts again comparing file by file and backlogging everything on the HOST.

3) RPS does not replicate the backup indexes, it is claimed that OBS will build these 'on the fly' as required, however if you have 300 customers that nobody has changed the default back time from 9pm be assured your OBS server will choke when it attempts to build indexes on the fly at that volume

4) You cannot disable SSL and Compression on RPS (that I can see) so you are wasting overhead using RPS as the data is already encrypted and compressed, this may be one of the reasons RPS is so slow.

Alot of this can be resolved by better programming processes.

Such as.

1) have a 'header' file for every file backed up, or a index file in each directory that indexes the last time a file was CRC checked, better yet store this information in the current indexes, it seems absurd to verify a files integrity, and then go ahead and modify the file by changing a line in a header immediately compromising its integrity.

2) Have an option of Delta Merge to instead of modifying the original file, merge these into a differential instead, minimising the need to re-replicate large files.

3) Have the backlog sent to RPS instead of holding these on the host, that way if you lose your primary storage you have the possibility of an option to 'replay' the backlog to the RPS data.

4) More RPS options, such as replicate 'at completion of backup' this way you can replicate the indexes as well, not wait until it so happens to pass thru a 'UNSYNC or 'SYNC' mode of replication

5) have RPS 'do more of the work' at present much of the CPU overhead for RPS is placed upon the OBS server, not the RPS. RPS does very little in the way of actual work.

The way the current system is the scalability of Ahsay and using RPS is very limited once you reach over about 1TB of OBS data.

1. Do not send RPS over a VPN. It is not needed and adds significant overhead. 2. Ensure both OBS and RPS have sufficient bandwidth going between the two. I have seen removing a rate limiter allow the RPS to catch up. 3. Split the OBS into 2.5-3.5 TB chunks. RPS can only process so many files in its single threaded directory list.

RPS does a pretty good job if you can get it into logging (other than index rebuild in a DR). We have all of our data in logging between our data centers.

I did look into getting expensive hardware SANs or software solutions. In the end, a little patience and admin work to divide the customer base paid off.

THanks!

Greg

KorComputing.com is a leading provider of Ahsay Backup Servers and Ahsay Replication.

Looked at using Azure, problem #1 - Azure has a max of 1Tb drives. This isnt enough a couple of individual OBS accounts. You can map directly to the Azure file storage, increasing the max size to 5Tb - which would work if we could map a file share per client, however there no nice way to map. I'm using mklink at the moment which (as far as Explorer is concerned) works fine, but RPS does not see the folder. From what I can tell, the reason for this is because the account RPS runs as does not have access to the share. Giving the system account the same login as the Azure file storage is not possible.

Is there any other way to break up the amount of space utilised by a single RPS server, rather than everything going into rcvshome? Can individual accounts within OBS be replicated to different drives? - or have some accounts not replicated at all? Is there a better way to set the "home" folder to a network location?

The difference is that for replication to cloud/FTP/SFTP, you don't have to provision another CBS machine, hence save the cost for buying another CBS license. But the trade-off is that, you can't switch the replication into your backup server quickly when your primary CBS is down. Hope it helps.