Introduction

Backing up a database to another server is usually about two separate concerns: creating a reliable backup artifact and transferring it safely to an off-host location. The exact command depends on the database engine, but the workflow is always the same: dump, transfer, verify, and automate.

Think in Terms of Backup Workflow, Not One Command

A good off-server backup process usually has four stages:

1. create a consistent dump or snapshot
2. send it to another server securely
3. verify that the backup is usable
4. automate retention and cleanup

A backup is not complete just because a dump file exists. It is complete only when you can restore it and prove it is valid.

MySQL and MariaDB Example

A common logical-backup pattern for MySQL or MariaDB uses mysqldump.

mysqldump -u backup_user -p --single-transaction appdb > appdb.sql

Then transfer it to the backup server:

scp appdb.sql backup@backup-server:/srv/db-backups/

You can compress on the source side to save bandwidth:

mysqldump -u backup_user -p --single-transaction appdb | gzip > appdb.sql.gz
scp appdb.sql.gz backup@backup-server:/srv/db-backups/

--single-transaction is useful for transactional engines because it reduces locking during the dump.

PostgreSQL Example

For PostgreSQL, pg_dump is the usual logical-backup tool.

pg_dump -U backup_user -F custom appdb > appdb.dump

Transfer it:

scp appdb.dump backup@backup-server:/srv/db-backups/

Restore testing can later use pg_restore, which is one reason the custom format is popular.

Restore Testing Matters More Than People Expect

A backup that was never tested is only a hopeful file. At minimum, regularly test a restore onto a non-production instance.

MySQL restore example:

mysql -u restore_user -p restored_appdb < appdb.sql

PostgreSQL restore example:

createdb -U restore_user restored_appdb
pg_restore -U restore_user -d restored_appdb appdb.dump

If restore fails, your transfer pipeline may still look healthy while your recovery plan is actually broken.

Secure Transfer and Storage

Since database backups often contain sensitive data, transport and storage should be treated as security-sensitive operations.

Reasonable defaults include:

• transfer over SSH with scp or rsync -e ssh
• limit filesystem permissions on the backup server
• encrypt the backup at rest if the risk model requires it
• use a restricted backup user instead of application admin credentials

A practical transfer with rsync looks like this:

rsync -avz appdb.sql.gz backup@backup-server:/srv/db-backups/

rsync is especially useful when you are synchronizing backup directories rather than one-off files.

Automate the Job Carefully

A scheduled job is normal, but do not stop at scheduling the dump itself. Automate rotation and alerting too.

Example cron entry:

0 2 * * * /usr/local/bin/run-db-backup.sh

A shell script behind that schedule might:

• create a timestamped dump
• compress it
• transfer it
• delete old backups after retention limits
• write logs and fail loudly on errors

Simple automation is good. Silent failing automation is dangerous.

Logical Dumps Versus Physical Backups

Logical dumps are easy to understand and portable, but they are not always the fastest or best choice for very large systems.

For bigger databases, you may need:

• engine-specific physical backup tools
• filesystem snapshots
• replica-based backup strategies
• point-in-time recovery using logs or WAL/binlog archives

So "backup to another server" does not necessarily mean "always use a SQL dump." It means choose a backup method that matches your size, recovery-time target, and consistency requirements.

Common Pitfalls

The biggest mistake is calling a dump successful without ever verifying restore. A backup that cannot be restored is not a backup in any meaningful operational sense.

Another issue is embedding powerful database passwords directly in scripts. Use restricted accounts and a safer credential management pattern where possible.

Teams also forget retention. If every nightly backup is kept forever on the remote server, storage will eventually become the next outage.

Finally, do not ignore application consistency. For active systems, choose backup flags and strategies that produce a consistent snapshot rather than a random moving target.

Summary

• Backing up to another server means dump, transfer, verify, and automate.
• 'mysqldump and pg_dump are common logical-backup tools for MySQL and PostgreSQL.'
• Transfer backups securely with SSH-based tools such as scp or rsync.
• Always test restores on a non-production target.
• Pick the backup method based on your recovery needs, not just on what is easiest to script.