Omdat storage replicatie duur is en applicaties niet in de replicatie betrokken zijn, kan het vaak handig zijn om de applicatie zelf voor de replicatie van de data te laten zorgen. Om replicatie op applicatieniveau te realiseren, moet er op beide locaties een server zijn. Deze servers draaien beide een applicatie die een eigen methode van datasynchronisatie heeft. Bijvoorbeeld databases en mailservers slaan alle transacties op in logfiles die vervolgens naar het secundaire systeem worden gestuurd. Dit passieve systeem injecteert deze logs vervolgens in diens eigen datakopie. Deze methode kan resulteren in verlies van data als afgesloten transacties op de hoofdlocatie nog niet gerepliceerd zijn naar de uitwijklocatie en vervolgens de hoofdlocatie uitvalt. Door dit juist in te richten kan dataverlies worden beperkt maar zal nooit nihil zijn. Het voordeel van applicatiereplicatie is dat het stand-by systeem gegarandeerd consistent kan worden gemaakt.

NetApp & Replicator Datacenter

Voor Disaster Recovery (DR) levert NetApp de SnapMirror functionaliteit. Snapmirror is bedoeld om data in de primaire site te repliceren naar een secundaire site waar een exacte kopie van de data wordt bijgehouden. Deze site kan dan in geval van calamiteit de functionaliteit van de primaire site overnemen zodat productie door kan gaan.

Figuur 9: Disaster Recovery

Door het gebruik van Snapmirror netwerk compressie technologie kan tot 70% bandbreedte bespaard worden in het replicatieverkeer.

SnapMirror ondersteunt de volgende methodes van replicatie: 

• Synchronous
• Semi-synchronous
• Asynchronous

Met behulp van managementsoftware zoals provisioning manager is het mogelijk om de replicatie in het gehele storagenetwerk in één ooggopslag te beheren. Hiermee wordt een storageomgeving gecreëerd waarin snelle disaster recovery mogelijk is voor belangrijke applicaties zoals Exchange, SQL en Oracle.