# FAQ

Questions related to database backups, database dumps, and connections

## My database server doesn't allow external connections. Can I back it up?

Yes, you can!

SimpleBackups supports SSH tunneling, meaning you can leverage another server (tunnel) that has access to the server you want to back up. You may also, instead, use our Tailscale integration to easily access your private resources without exposing them to the internet and without having a jump/bastion server.

## How to back up private and internal databases?

**Summary:**
Back up privately/internally-accessible databases (MySQL, PostgreSQL, MongoDB, Redis) behind firewalls.

It is possible to use SimpleBackups to back up private resources. You will need an intermediate server within your network that has access to the private network, and use that intermediate server during the backup.

Using this method, the private host is never accessible or exposed to the Internet, and at the same time no agents are run on the private server to take the backup. The private host stays as a blackbox.

### Requirements

1. Private database, or server you need to back up (ex.: **`private-resource-01`**)
2. Any SSH-accessible intermediate server, that has access to the resources in **step 1** (ex.: **`tunnel-server-01`**)

### Backup Internal or Private Databases (database backups)

Expose the private database that resides on **`private-resource-01`** to an intermediate SSH-accessible server **`tunnel-server-01`**, then:

1. Create a serverless database backup on SimpleBackups
2. Use the tunnel option to tunnel SimpleBackups' connection through **`tunnel-server-01`** which has access to your privately accessible database

## How do I migrate to the new serverless workers?

SimpleBackups has updated its serverless workers with support for the latest versions of MySQL and PostgreSQL dumpers. If your backups are running on older workers, you should migrate to avoid compatibility issues.

To check if you are using the old workers, look for the migration indicator on your backup detail page.

![The backup detail page showing the old worker indicator](https://simplebackups.com/docs/docs-assets/media-helpkit-co/fa13f752ef1297677c7d.png)

![A closer view of the old worker status](https://simplebackups.com/docs/docs-assets/media-helpkit-co/4daa9f0119563d5e7c33.png)

Before migrating, whitelist all SimpleBackups IP addresses in your database firewall. See [SimpleBackups IP addresses](https://simplebackups.com/docs/help-tips-and-troubleshooting/connecting-a-server/simplebackups-ip-addresses-firewall) for the full list.

Once your firewall is updated, open the **Actions** dropdown on your backup and click **Upgrade to new serverless**.

![The Actions dropdown with the Upgrade to new serverless option](https://simplebackups.com/docs/docs-assets/media-helpkit-co/6fa69b662a8e47a8a395.png)

Click **Confirm** and wait for the process to complete.

![The migration confirmation dialog](https://simplebackups.com/docs/docs-assets/media-helpkit-co/ebf8cd83d465e59edcab.png)

After the migration finishes, your backup info will reflect the new worker.

![The backup detail page showing the new worker status](https://simplebackups.com/docs/docs-assets/media-helpkit-co/ab0982541378e09a9269.png)

## Database size is smaller after restore

A backup could certainly be much smaller than the actual size of the database.

The trusted way to confirm the consistency of a backup is in fact restoring and inspecting the backup.

**Info:**
It is also normal to see that a restored database is actually smaller than an already existing database, especially for Postgres. Reasons for the size difference include rebuilding indexes and defragmentation.