Data usage and structure not discussed, but very important to choosing a backup solution.
A key thing that appears to have been missed, is about the type of data being stored and how that data is used, for example, if all you ever do is append data, i.e. nothing is ever deleted, then replication is a perfect form of backup, because you never have to roll the system back, so provided that you can ensure consistency between the two copies, all you ever need to do, is add a new entry that is correct to supersede the old information. If you need to see what the data looked like at a particular point in time, then you just ignore all data after that time.
Where using replication is more difficult to justify as a form of backup, is when data is changed or deleted, because the changed data is no longer kept in the data structure and the blocks on which the data was stored could be re-used, this makes it possible to look at the data as it was at a previous point in time.
You can get around this in some cases by partitioning data, an example of this is in compliance environments where you must retain data for X and destroy it by Y. Between X and Y is an amount of time, you halve it and that is your partition period. A partition (once created) is active for the duration of one partition period and data may only be appended to it during the time that it is active, at the end of the period the partition becomes read only and a new active partition is created for new data. Once the newest piece of data in any partition reaches the end of the retention period, the partition and all data within it is destroyed.
This is fine, when you work with systems, where the data structure is designed to have old entries retired, a classic example of this is a financial system, which records a transaction and a running total with each entry. We can see this with an example for a bank statement, when we look at statements, your bank statement is designed to be completely stand alone, for example:
Balance in: £4135.83
Credit - Pay £1982.32
Debit - Electricity £250.12
Debit - Gas £35.00
Debit - Apple Store £599.99
Balance Out: £5233.04
Your bank statement contains the incoming balance, the transactions that took place within the statement period and the outgoing balance. Next month, you'll get a new statement with the new information, if all you care about is how much is in your account, you can shred the old one and it has no repercussions on the new statement, however, if you care about how much you spent on Gas last January, you will keep the statement for as long as that information is relevant.
Financial systems are ideally suited to this kind of process, because bank accounts are not generally related to each other and retention periods are always longer than a year, every account that has not been closed will be updated at least once a year when interest is calculated, this means that there is always a current record in a partition that is within it's retention period and the closure of one account does not affect the status of another.
This is fine... but what happens if you have a relational database and different elements within the database having different retention periods for compliance reasons, a typical example might be a case management system for use in law enforcement, where there will be People (or organisations), Objects (e.g. Vehicles, Weapons), Locations and Events (Phone call, robbery, stabbing) stored within the system and related in any number of ways. The answer is that you cant easily partition this data, so the application has to manage the data's life cycle, retention and disposal and the applications repositories have to have snapshots copies taken at regular points in time in order to ensure that it's possible to go back to a specific piece of information as it looked at that time. Another method is that the application can store a snapshot of elements related to a case within the case record, this helps to insulate against differing retention policies at the expense of storage, it also can make predicting the rate of change difficult, especially if cases become inter-related.
For data that like this that is not linear, you can back the data up to tape as a snapshot, or use a disk based technology and replicate the disk and the snapshots to a second system, but every snapshot technology in the market works on the principle of space reservation, i.e. a certain amount of space is reserved for changed data that pertains to a specific snapshot. If the live volume runs out of space or the rate of change is too great, snapshots will be retired in order to preserve the live data or the most recent snapshot(s), if your business needs to keep a copy from a year ago for any reason and you do not manage the storage system, ensure sufficient space is always maintained and that data change is kept fairly constant or at a predictable rate, it's likely that you will run low on storage and the oldest snapshots will begin to vanish prior to their retention period ending.
What this means is that if the rate of change of your data is massive or unpredictable, then you need to have incredibly large amounts of storage available for the space reservation on both your primary storage and your replica, otherwise your likely to fall out of compliance with your backup retention policy. There are other things to think about if your rate of change spikes. What about the links between the replica's? Will the changes be written to the replica fast enough? If the system is synchronous, will performance of the application be impacted while the system waits for the replica system to confirm the data has been committed?
Replication can do the job, if the volumes and rate of change for data are well understood, or if the data stored has certain characteristics, however, for most cases tape is easier to manage, easier to dispose of and could be more economical to store.