Man kann jederzeit einen komplett funktionsfähigen Backup-Standort unterhalten – das ist nicht gerade billig. Oder man kann hoffen, dass man im Falle des Ausfalls schnell ein neues Rechenzentrum aufbauen kann – das ist alles andere als sicher. Double-Take Cloud vereint die Vorteile beider Extreme: Auf allen kritischen Produktiv-Servern werden Agents installiert, die Änderungen an den Daten und am Systemstatus in die Cloud replizieren. Da ja nur das Repository kontinuierlich läuft, ist das System ressourcenschonend und leicht zu beherrschen. Die Replikation wird auf Byte-Ebene durchgeführt und wird in ihrer Geschwindigkeit nur durch die zur Verfügung stehende Bandbreite beschränkt, oder von den Grenzwerten, die in Double-Take Cloud definiert werden. Damit läuft die Replikation der Produktiv-Server auch im WAN effizient und nahezu in Echtzeit, wenn ausreichend Bandbreite zur Verfügung steht. Aber auch wenn die Übertragung wegen beschränkter Bandbreite gedrosselt werden muss: Double-Take Cloud erlaubt dennoch die Wiederherstellung jedes einzelnen Bytes, das seinen Weg in den Repository-Speicher gefunden hat.
Müssen einer oder mehrere kritische Server wiederhergestellt werden, kann das Repository genutzt werden, um von dort alle System-Staus-Informationen sowie alle Binärdaten von Windows und Programmen auf einen Cloud-basierenden Backup-Server zu verlagern. Dieser Server wird nur bei Bedarf aufgesetzt, er muss also nicht gewartet, auf den neuesten Stand gebracht oder in irgendeiner Form überwacht werden. Der virtuelle Backup-Server in der Cloud wird per Online-Formular erst gekauft, wenn ein Recovery erforderlich ist. Danach konvertiert der Double-Take Cloud Recovery Wizard die ausgelagerten Daten in ein Cloud-System, das an die Stelle des ausgefallenen Produktiv-Servers tritt. Der Produktiv-Server selbst ist bei dieser Art des Recovery nicht mehr erforderlich. Der Betrieb kann also auch nach massiven Hardware-Ausfällen reibungslos weitergehen.
Die Cloud ist eine praktikable Plattform für Tests, Entwicklung, Qualitätssicherung und andere Back-Office-Aufgaben. Oft dient die Cloud aber auch als primäre Geschäfts-Infrastruktur, die bei Bedarf schnell verlagert oder skaliert werden kann. Das Problem dabei war aber immer die Verlagerung der aktuellen Back- oder Front-Office-Servers in ein virtuelles System eines Cloud Service Providers (CSP), und das im laufenden Betrieb. Eine gewisse Downtime ist zwar vom Back-Office-Team noch abzufangen, sie sollte aber dennoch so kurz wie möglich sein. Eine längere Service-Unterbrechung bei Front-Office-Anwendungen ist dagegen generell inakzeptabel. Es bleibt außerdem noch die Frage nach der Kompatibilität der Programme und Betriebssysteme, denn Produktiv-Server laufen oft auf physischer oder virtueller Hardware, die vielleicht nicht zum CSP passt.
Mit Double-Take Cloud steht eine einfache Methode für die Migration in eine Cloud-Infrastruktur zur Verfügung, die nur mit einer minimalen Downtime einhergeht. Alle im Betrieb befindlichen Server werden mit der Software Double-Take RecoverNow ausgestattet und beginnen sofort damit, Systemstatus, Programme und Daten auf ein CSP-Repository zu replizieren. Ist die erste Komplett-Spiegelung abgeschlossen, werden alle neuen Informationen sofort wieder repliziert, so lange bis die Umstellung vollzogen wird und die Entwickler in der Cloud genau dort weitermachen können, wo sie auf dem lokalen Server aufgehört haben. Dieser bleibt während des gesamten Migrationsprozesses verfügbar und zugänglich. Erst kurz vor der Umstellung auf die Cloud werden die neuen virtuellen Server beim CSP angelegt und online geschaltet, zunächst noch mit einer temporären Server-Identität.
Im Rahmen der Umstellung werden die alten lokalen Produktiv-Server heruntergefahren, und Double-Take Cloud legt im Repository Kopien dieser Server auf der Basis der Replikate an. Was normalerweise Tage dauern würde, kann nun in ein paar Stunden durchgezogen werden. Dabei überbrückt Double-Take Cloud alle Hardware-Differenzen. Sofort nach der endgültigen Migration können die Anwender das neue System nutzen. Bei dieser neuen Remote-Verbindung bleibt für den User alles wie gehabt, sowohl bei den Server-Identitäten als auch bei Daten- und Informationsbeständen.