Backup As Code

What is Backup As Code?

The new trend strives to have integrated backups with the product and services configured. This is sometimes called “Backup As Code“, or “integrated backup“.

This requires that the the backup is taken at a specific point in time when the application wants it to be taken, and not when an external scheduler fires up this, using typically an agent.

The backup taken may also include application and/or service specific data that should be included when the backup is taken. This might be complicated to perform using “agents”, as they are often designed to perform backups of a specific data, such as an Oracle database, SQL Server etc.

What is Agentless backups?

Agentless backup is where no service, daemon or process (AKA an agent) needs to run in the background on the machine the action is being performed on.

In reality all computer tasks requires related programs to run and these programs could be considered as agents. However the controlling machine may use an agent, while its target is agentless in that it need not install or run new software related to the task itself.

What is integrated backups?

Applications often comes with a way and method to perform backup and restore of the systems. This is often refering to backup to a path on the server.

The issue with these methods is that a backup that are locally stored on the same server where the protected data exists, are in higher risk to also be affected by ransomware attacks, human errors, bugs, hardware errors, and external errors such as flooding, fire, earthquakes, terrorism etc.

The way how this have been performed traditionally is to install an agent to protect the application data, and of load this to a remote location.

The issue with using with replacing the way how the backups is intended to be performed is that you might break the compliances from the vendor of the product and/or services.

Compliant backup

We believe that by following the way how the applications are designed to perform backup and restores will make it much more easy to be compliant.

It will also be much more easy to find skills supporting the solutions, as the routines to backup and restore the solution uses the way how the application and/or services is designed.

We think it is advisable having the backups visible for the users (“Seeing is believing”), so that they can more easy perform the tasks required using native operating system commands.

The backups must be protected from unauthorized access, which we believe can be performed using native access control rules + backup storage access policies.

Is this possible?


Mounting Spictera SPFS filesystem on the servers makes the backup and restore seamless. Just use the way how the applications and/or services is designed to protect the data, by pointing our or mounting the Spictera SPFS on the location where the data should land.

Scroll to Top