Asigra cloud backup review

Asigra is a product that swings both ways - it can be set up as your own cloud or as backup as a service: your choice

An illustration of a man sitting at a desk using a computer, with his local files being backed up to a server and the cloud
(Image: © Shutterstock)

CloudPro Verdict


  • +

    Able to back up a vast array of different types of client system; DS-Client has its own database which caches key data; Backups encrypted and compressed; Pay-as-you-go model based on the amount of data you store.


  • -

    GUI isn't the best, though you soon get the hang of it; Backup speed is, of course, proportional to your bandwidth.

Asigra is an interesting beast, in that the product is only really available as a cloud service product via resellers. Put simply, it's designed for people who want to back up their systems into cloud-based repositories.

There are two main components to the package: the DS-System (the server end) and the DS-Client (unsurprisingly, the client end). There are a couple of additional items that you'll end up using too, however. First is the DS-Operator application, which is a GUI-based management tool that you use to control the DS-Server. Second is DS-User, which is a GUI-based app that you use to control the DS-Client (the latter is basically a faceless background service that just sits there being a backup engine; the DS-User app connects to the service to let you manage it).

The first step to running a backup in an Asigra setup is to create the customer on the DS-Server – a simple two-minute wizard that asks for unexciting things such as the customer name. Within each customer you then define clients: each client will later have a DS-Client registered against it. You define an account code and a name, and it'll generate you a unique code; once that's done, you're good to set up the client end.

The setup has three tiers. The server sits in the provider's data centre and each customer site has one or more DS-Client machines, each of which backs up multiple endpoints (without the need for an agent app on each). The DS-Client mediates between the endpoints and the DS-Server, and keeps its own database of backup details. This latter bit is important, incidentally: when you install the DS-Client it asks you to point it at a database or it installs one of its own (SQL Server Express if you're installing on Windows, for example).

When you first install the client you're prompted for the account code that you set up at the server end and an encryption key. This key is used to encode the backed-up data, and if you lose it you're properly stuffed as your backups will be unrecoverable: either store a copy in your secure password repository or export the config of the client to somewhere safe. Once the client has registered with the server you're good to go.

I've done both Windows backups and VMware hypervisor-level backups using Asigra. The only problem I've found is that the GUI of the DS-User app is never going to win any awards for user-friendliness, so it's sometimes not obvious how to do things (navigating a Windows network to find the machine you're looking for, for instance). This said, though, it's very much the case that once you've done each task once you'll not have trouble with it again. In terms of defining backups it's pretty much a case of telling it what to back up and then defining a schedule to drop the job into. One cunning feature, though, is the ability to define sub-schedules within a schedule – so you can have a daily backup schedule and then define a sub-schedule to (say) make an archive on offline storage on a weekly or monthly basis.

The approach to backups is to start with a full dump and then work incrementally from there. If you have a big repository and a slowish link you can “seed” the backup via a disk-based copy that's uploaded manually to the server, then kick off your incrementals once this has been done.

Restoring files is another wizard-based concept, and as you'd expect you can either restore a file to its original location or drop it somewhere else if, like me, you want to be sure not to blow away something important. It's tasks like this that make the DS-Client's local database invaluable – by having the information locally it doesn't have to pull a directory out of the cloud in order to give you the directory listing to pick your files from.

Aside from a handful of “How do I make it do XXX” questions, I've had no problems with Asigra. I've backed up Windows machines via a Windows client, and done hypervisor-level VM backups from a Linux-based DS-Client, both of which were pretty uneventful. The reporting is, incidentally, comprehensive and useful; particularly important are the usage reports because licence payments are based on stored data volumes.

There's one “gotcha”, though – and it's not a problem as such, just something you need to bear in mind. If you're running the DS-Client with its own local database (which will be the usual setup, I reckon) you'll not want less than 4GB RAM (I've tried it on 2GB and it wasn't pretty), and enough disk space for the database to work in. Also bear in mind that because data is being encrypted and compressed, you'll not want to skimp on CPU provision either as the backup speed can easily become limited by available CPU resource – particularly if you have a fast link.


Asigra is a versatile cloud-based backup system whose GUI takes a bit of getting used to but which is flexible and, assuming you have decent connectivity in place, fast.