Card 1
What are the two main backup modes?
logical exports database objects through client tools, APIs, or query protocols. physical captures engine files, native backup pieces, or snapshots.
Fast reference cards for logical vs physical backups, destination rules, cloud staging, database support, restore safety, and operator prechecks.
logical exports database objects through client tools, APIs, or query protocols. physical captures engine files, native backup pieces, or snapshots.
Use logical backups for portable exports, schema/table/document-level workflows, managed databases, and object-storage streaming.
Use physical backups for self-managed engines when a native physical format is required, such as pg_basebackup, data directory archives, RMAN pieces, SQL Server .bak, Neo4j dumps/backups, or Cassandra snapshots.
Physical tools usually must read database-host files or write server-visible artifacts. DBAegis normally runs those over SSH on the DB VM and stages under db_vm_temp_dir or server_temp_dir.
DBAegis resolves the connection, backup type, destination, and options, runs the engine-specific tool, writes the artifact, records history, saves logs, and redacts secrets.
DBAegis validates the restore source, target connection, restore type, and safety prompts, prepares any local or DB VM staging, runs the engine-specific restore, records logs, and marks the job success or failed.
Restore Type is selected first. Logical restores show logical connections; physical restores show physical connections.
A separate test or recovery target. Physical restores and overwrite/drop/truncate options can be destructive.
A non-mutating validation path that checks submitted restore parameters where the engine supports it.
overwrite_existing generally mean?DBAegis may replace target files, flush target data, recreate databases, or allow native overwrite behavior depending on the database engine.
db_vm_temp_dir?A database-server staging path used when the DB host must hold a temporary backup or restore artifact.
DBAEGIS_TEMP_DIR?The DBAegis VM scratch path, defaulting to /opt/dbaegis/tmp, used for local restore preparation, temporary cloud files, SSH keys, and client-side managed-service work.
It checks database connectivity, SSH readiness, required tools, temp path write access, disk space, run-as behavior, cloud destination access, and physical restore safety.
No. It checks readiness only. Restore source paths and destructive options are validated again when the restore job is submitted.
Backup and restore rows store status, target/source paths, command text, exit code, stdout/stderr snippets, engine logs, and redacted error messages.
DBAegis local file, DB server local, AWS S3 or S3-compatible storage, Google Cloud Storage, and Azure Blob.
DBAegis local file?The finished artifact is stored on the DBAegis server filesystem, normally under /backups unless a local storage destination path is configured.
DB server local?The artifact is written to a path visible to the database server. Client-tool engines require SSH remote execution so DBAegis can run the command on the DB host.
A configured S3 or S3-compatible bucket/prefix. DBAegis records and restores objects with canonical s3://... URIs.
s3, aws, amazon, s3compatible, s3-compatible, and minio.
A configured GCS bucket/prefix. DBAegis records and restores objects with canonical gcs://... URIs.
gcs, google, google_cloud_storage, google-cloud-storage, gcp, gs, and gs://... restore sources.
A configured Azure Blob container/prefix. DBAegis records and restores objects with canonical azure://... URIs.
azure, az, azblob, azureblob, azure_blob, azure-blob, blob, and az://... restore sources.
It writes and deletes a small .dbaegis-precheck/ object for S3, GCS, or Azure Blob using the saved credentials and prefix.
No. Storage credentials are encrypted at rest with key material derived from DBAEGIS_SECRET_KEY and redacted in UI/API responses.
Backup execution rejects the selected destination before running the database tool.
Cloud restore fails with a source/storage mismatch, such as an s3:// source with a GCS destination.
DBAegis streams or uploads the backup directly to S3, GCS, or Azure Blob without first creating a DB-host file artifact.
DBAegis runs the native tool on the DB VM, writes a temporary artifact under DB VM staging, streams or copies that artifact to cloud storage, then removes the temporary file.
PostgreSQL, MySQL, MariaDB, MongoDB, Redis / Valkey, CouchDB, Neo4j, Cassandra, ClickHouse, SQL Server BACPAC, Azure SQL BACPAC, Snowflake, Cosmos DB, DynamoDB, and Firestore.
Physical/file workflows for PostgreSQL, MySQL, MariaDB, MongoDB, Redis / Valkey, SQLite, Neo4j, SQL Server, Oracle, and Cassandra. Oracle logical Data Pump also uses DB VM staging.
Enterprise native object-store mode can write directly to object storage when explicitly selected. The default/community path creates a DB VM archive and uploads a tarball.
DBAegis reads the object from S3, GCS, or Azure Blob and streams or replays it into the target database through the client tool/API.
DBAegis downloads or streams the cloud object to a DB VM temp path over SSH, runs the native restore from that server-visible path, then removes staging files.
Logical and physical. All five destination/source families are supported. Logical uses pg_dump/psql; physical uses pg_basebackup with DB VM staging in split-VM workflows.
Logical and physical. All five destination/source families are supported. Logical uses mysqldump/mysql; physical uses xtrabackup or snapshot-safe datadir archives on the DB VM.
Logical and physical. All five destination/source families are supported. Logical uses mysqldump/mysql; physical uses mariadb-backup, mariabackup, or snapshot-safe datadir archives.
Logical and physical. All five destination/source families are supported. Logical uses mongodump --archive and mongorestore --archive; physical archives dbPath for self-managed deployments.
Logical and physical. All five destination/source families are supported. Logical exports supported key types as JSON; physical captures RDB/AOF artifacts for self-managed targets.
Logical and physical file workflows. All five destination/source families are supported, but split-VM backup and restore require SSH or an explicit shared mount because the database is a file.
Logical only. All five destination/source families are supported. Backup uses HTTP document export; restore imports through _bulk_docs.
Logical cbbackupmgr archives only. All five destination/source families are supported. Cloud uses Enterprise native object-store mode when selected or DB VM staged tarballs for default/community mode.
Logical and physical. All five destination/source families are supported. Logical uses Cypher; physical uses neo4j-admin dump/load or online backup/restore modes.
Logical BACPAC supports DBAegis local, S3, Azure Blob, and GCS. Physical .bak backup supports DBAegis local, DB server local, S3, Azure Blob, and GCS; physical restore uses a SQL Server-visible DB server or cloud-staged .bak.
Logical Data Pump and physical RMAN. Backup supports DBAegis local, DB server local, S3, Azure Blob, and GCS. Restore uses DB-server-visible or cloud-staged Oracle artifacts.
Logical and physical. All five destination/source families are supported. Logical exports one table as CSV.GZ; physical uses nodetool snapshot and nodetool refresh.
Logical only. All five destination/source families are supported. DBAegis stores a .clickhouse.json.gz archive with DDL and JSONEachRow table data.
Logical only. DBAegis local, S3, Azure Blob, and GCS are supported through SnowSQL on the DBAegis VM. There is no DB server local path because Snowflake is managed.
Logical only. DBAegis local, S3, Azure Blob, and GCS are supported. Backup and restore use live service APIs and JSON documents.
Logical only. DBAegis local, S3, Azure Blob, and GCS are supported. Backup and restore use live service APIs and JSON item documents.
Logical only. DBAegis local, S3, Azure Blob, and GCS are supported. Backup and restore use live service APIs and JSON document paths/data.
Logical BACPAC only. DBAegis local, S3, Azure Blob, and GCS are supported. Physical backup is provider-managed outside DBAegis.
DBAegis exposes the dropdown only where the native tool has a real supported mode flag. Other engines keep normal options instead of showing a no-op selector.
Incremental/default and full. Full adds --full-backup; incremental/default lets cbbackupmgr continue the existing archive chain.
cbbackupmgr manages the archive chain. A forced full can be selected when an explicit new full archive is needed.
Dump, full online backup, differential with full fallback, and online default. Differential with full fallback uses --type=AUTO, so Neo4j creates a full when no valid chain exists.
Full, differential, and copy-only. Differential adds WITH DIFFERENTIAL; copy-only adds WITH COPY_ONLY; full adds neither clause.
Full, incremental level 0, incremental level 1 differential, and incremental level 1 cumulative.
It is an RMAN incremental baseline that can support later level 1 differential or cumulative backups.
It backs up blocks changed since the most recent level 0 or level 1 backup in the chain.
It backs up blocks changed since the most recent level 0 backup.
Physical restores and options that overwrite, replace, clean, drop, truncate, recreate, restore users/roles, or stop services.
DBAegis requires admin session auth, a restore reason, password re-authorization, and exact target-name confirmation where applicable.
Yes for supported engines. Examples include PostgreSQL/MySQL target database, MongoDB namespace remap, CouchDB target database, Cosmos target database/container, DynamoDB target table, and ClickHouse target database/table.
Confirm the source URI, selected storage destination, provider credentials, bucket/container/prefix permissions, target database connection, and any DB VM temp path required by the engine.
Confirm the target host is isolated or stopped as required, target data paths are correct, the DB VM has enough free space, SSH/run-as works, and the native restore tool is installed.
DBAegis classifies the failure as DBAegis filesystem, DB server filesystem, or DB server staging filesystem full/quota depending on where the write failed.
DBAegis records a cloud storage access failure and points operators toward credentials, IAM/KMS/SAS/service-account policy, endpoint, region, bucket/container, or prefix permissions.
No. Self-backups protect the DBAegis metadata/config state and are restored from the DBAegis VM shell, not through database restore jobs.