Uitgangspunt bij SaaS is dat klanten eigenaar zijn van hun data en ten allen tijde toegang willen hebben tot deze gegevens. De beschikbaarheid wordt over het algemeen beschreven in de service level agreement (sla) en bedraagt in de meeste gevallen minstens 99,8 procent. Helaas kan het altijd gebeuren dat er iets mis gaat en dat hoeft in veel gevallen niet aan de SaaS leverancier of software te liggen. Er kan zich een calamiteit voordoen of klanten kunnen per ongeluk hun eigen data verwijderen. En dan? Onderstaand worden een aantal backup strategieën genoemd waarmee klant en leverancier samen het risico van data verlies kunnen beperken.
Rapportages: Gebruikers kunnen zelf rapporten aanmaken met bijvoorbeeld hun inventaris of contacten en deze als CSV downloaden. Het voordeel is dat dit op elk moment gedaan kan worden. Een nadeel is dat de data vaak geformatteerd of getransformeerd is, bijvoorbeeld om datums goed weer te geven, en dus geen directe afspiegeling is van de brongegevens in het systeem.
CSV/XML dumps: Gebruikers kunnen essentiële data selecteren op basis van filter criteria, zoals bijvoorbeeld modificatie datum, regio of kostenplaats. De data wordt vervolgens ongeformateerd in een CSV- of XML-bestand weggeschreven. Dit kan vervolgens periodiek automatisch via ftp of email verstuurd worden. De dump is meestal geen 100 procent weergave van de data omdat bepaalde (meta) data door de SaaS leverancier afgeschermd kan zijn. Een volledige dump van alle data is op deze manier over het algemeen niet mogelijk.
Document dumps: In de meeste systemen wordt met een combinatie van records en documenten gewerkt. Voor export van documenten is een CSV/XML-dump niet efficiënt en moet een alternatief aangeboden worden, bijvoorbeeld in de vorm van een dump naar een ftp-server. Probleem is dat het datavolume van documenten meestal hoog is en een volledige dump niet efficiënt is. Daarnaast zijn er problemen met de opslag van de dump. Er kunnen uiteraard meerdere documenten met dezelfde naam bestaan en deze zullen dan op een of andere manier via directories gestructureerd moeten worden.
Native database dump: De meeste SaaS-leveranciers zullen gebruik maken van een relationele database en via een dump kan in principe een volledige dump van de data en metadata aangeleverd worden. Nadeel is dat het database schema niet altijd gedocumenteerd is en in de loop van de tijd kan veranderen. Een native database dump kan in sommige gevallen ook documenten bevatten. Voor het teruglezen van de data moet de klant een compatibele relationele database installeren. De dump kan als abonnement via dvd of per ftp beschikbaar gesteld worden.
SQL database dump: Als documenten apart zijn opgeslagen is het vaak mogelijk om een database onafhankelijke SQL dump te maken en een dump van het document file systeem. Voordeel is dat de SQL dump door verschillende systemen ingelezen kan worden. Er moet uiteraard beschreven zijn hoe de koppelingen tussen objecten in de database en bestanden in het file systeem geïmplementeerd zijn. Bij periodieke dumps hoeven alleen documenten die sinds de laatste dump nieuw of aangepast zijn opgenomen te worden.
Real time replicatie: Bij real-time replicatie worden alle transacties direct gemirrored op een hot standby systeem. Dit is vooral van belang om de beschikbaarheid van de omgeving te verhogen. Bij uitval van een databaseserver of corruptie van de database kan er direct overgeschakeld worden en is er nagenoeg geen data verlies. Replicatie heeft beperkte waarde omdat data die per ongeluk verwijderd wordt in de productie-omgeving ook direct automatisch verwijderd wordt in de standby omgeving.
Backup site: Van SaaS leveranciers mag verwacht worden dat ze backups maken. Het probleem is dat de klant dit moeilijk kan controleren en dat een restore lang kan duren. Een oplossing is het aanbieden van een backup site in een ander datacentrum. De backup site heeft dezelfde software als de productie-omgeving en wordt dagelijks gesynchroniseerd. Klanten kunnen op de backup site inloggen en de restore verifiëren. Door de synchronisatie maar eens per 24 uur uit te voeren hebben klanten een snapshot van hun data van de vorige dag. Als er per ongeluk iets verwijderd is, kan de data in veel gevallen via de backup site weer gerestored worden. In geval van grote calamiteiten wordt deze backup site (tijdelijk) productie site.
Private mirror site: Het concept is dat er een volledige mirror omgeving op een eigen server van de klant geïnstalleerd wordt. Deze wordt dagelijks automatisch gesynchroniseerd en eventueel door de SaaS-leverancier beheerd. Als de leverancier in gebreke blijft, of niet beschikbaar is, heeft de klant dus altijd zelf een draaiende versie van de productie-omgeving met recente data en bovendien kan de klant de backup elke dag verifiëren. Omdat deze omgeving alleen voor noodgevallen gebruikt wordt kunnen lagere eisen gesteld worden aan hardware, beschikbaarheid en connectiviteit.
Virtual server source code escrow: Veel SaaS-leveranciers bieden een source code escrow aan, maar het probleem is dat het installeren van de SaaS-omgeving op basis van source code complex en tijdrovend is. Dit kan worden opgelost door gebruik te maken van virtualisatie. Een volledig geïnstalleerde SaaS productie-omgeving met source code wordt als virtual disk (Hyper-V, VMware) by de source code agent deponeerd. Klanten kunnen bij noodgevallen de virtual disk uit het depot halen, installeren en hun database dump installeren.
Een goede backup strategie betreft niet alleen het maken van de backup zelf maar het hele proces van timing, restoring, transport en verificatie van data, productie-software en source code. Bij een SaaS-architectuur moet er uiteraard rekening gehouden worden met extractie van klant-specifieke informatie uit een multi-tenant omgeving. Veel van de bovengenoemde strategieën zijn overigens niet alleen van toepassing voor SaaS, maar zijn ook relevant voor beheerders van interne applicaties die verantwoordelijkheid hebben naar hun medewerkers, klanten en management.
Ieder bedrijf dat gebruik maakt van SaaS moet van zijn data een fatsoenlijke backup / restore en of disaster recovery kunnen maken. Ieder bedrijf moet een switch kunnen maken van het ene SaaS product naar het andere SaaS product waarbij de data geschiedenis op een fatsoenlijke manier kan worden meegenomen, dus geen vendor lock-in.
Nu is dat in de praktijk niet of niet altijd het geval, let er dus op voor het kiezen en bij het kiezen van een leverancier dat er o.a. aan deze eisen wordt voldaan.