Users can send data to the Backup Ninja service by using a locally installed agent called
bartender or through the HTTPS API with security token. This article describes the main security capabilities and features available to users to ensure their environment is secure.
Backup Ninja uses AES256 OFB encrytion mode via Go AES encryption package when encrypting a backup. When
bartender performs the backup routine, the streaming ouput (stdout) will be compressed (if enabled) and encrypted (if enabled) on-the-fly. No extra tool is required for compression and encryption.
bartender agent stores sensitive data in several locations. These files and directories must be configured properly to avoid information leakage. The following files and directories must be owned by
root user and must not be readable by global users:
/etc/bartender.yaml- Default configuration file.
/var/lib/backup-agent/(recursively) - Data directory.
/var/log/bartender.log- Default log file.
Backup Ninja is a SaaS product, whereby users need to establish an outbound connection from their network to the public internet in order to submit monitoring data. Traffic is always initiated by the
bartender agent to Backup Ninja via HTTPS connection. No sessions are ever initiated from Backup Ninja back to the
Outbound connection via proxy is not supported at the moment.
bartender agent periodically pulls the configuration (default is every 30 seconds) from a number of API endpoints:
agent-api.s9s.io:443- Agent configuration and reporting.
agent-backup-api.s9s.io:443- Backup configuration and job status reporting.
agent-auth-api.s9s.io:443- Agent authentication.
All communication to the API endpoints must be accompanied with a security token, which is uniquely generated by Backup Ninja when users add their database host.
Manual modification to
bartenderconfiguration will always get overriden by the configuration pulled from Backup Ninja API endpoints.
bartender stores backup jobs and backup metadata in a local SQlite database, located under
Some maintenance tasks are executed locally (without being instructed by Backup Ninja) for example, the backup purging process performed by the agent will look up the backup metadata stored in this local database, and push the state back to Backup Ninja API endpoints for reporting.
The encryption key is stored in the backup schedule configuration file of the agent host. The key must be a HEX representation of an AES256 key (256 random bits) which equal to 64 HEX characters (32 bytes), for example:
Currently, Backup Ninja will generate a random key for you when scheduling a backup. It's not possible at the moment to generate a different key or use your own key.
Note that only you have the key with at-source AES 256 encryption, so you are advised to store the key in a safe place. The key is not stored in the Backup Ninja SaaS service.
Backup Ninja stores some information about the node where it is running:
Note that Backup Ninja never sends internal data nor credentials outside the node.