Backups and Staging

Backups should include everything you need and be functional. Build a strategy that covers what to back up, how to back up each piece consistently, and how to restore it. Then prove the strategy works by restoring a production backup into a staging environment.

Creating a staging environment from your backup is a good test that you can restore your environments, and where you can run upgrade user acceptance testing before you touch production. Every restore you perform for staging is also a rehearsal for the restore you hope you never need in an emergency.

All three products keep state in two places that must agree with each other: a variable data directory on disk, and a metadata database (SQLite by default, PostgreSQL optionally). If the two are captured at different moments, the restore is broken in ways that may not be obvious at first.

Warning

Stop the service before backing up. A backup taken while the service is writing can produce a corrupt or inconsistent database. Capture the database and the data directory at the same point in time when the service is stopped.

What to back up

The Backup guides for each product give detailed information about how and what to back up:

The table below gives a short overview:

Product Config Data directory Database Keys / extras
Connect /etc/rstudio-connect/rstudio-connect.gcfg Server.DataDir (/var/lib/rstudio-connect) SQLite (in DataDir) or PostgreSQL (pg_dump) Database.Dir holds encryption keys; losing it makes secrets unreadable
Workbench /etc/rstudio/ (all of it) /var/lib/rstudio-server, /var/lib/rstudio-launcher, shared storage SQLite (/var/lib/rstudio-server/rstudio.sqlite) or PostgreSQL secure-cookie-key (signs cookies, encrypts the DB password); user home dirs for migration
Package Manager /etc/rstudio-pm/rstudio-pm.gcfg Server.DataDir (/var/lib/rstudio-pm) SQLite (in DataDir) or PostgreSQL license .lic, encryption key inside DataDir; S3-backed data backed up separately

How to back up

Preserve ownership, permissions, and symlinks when you copy files. Use rsync -a, cp -a, or tar -p, to ensure these attributes are preserved.

Back up PostgreSQL with its own tooling (pg_dump or a database snapshot), separately from the filesystem backup. A filesystem snapshot of a live PostgreSQL data directory is not a reliable backup.

Stop the service before you back it up:

  • Workbench: run rstudio-server suspend-all first to preserve session state, then rstudio-server stop.
  • Connect and Package Manager: systemctl stop the service.

In a multi-node deployment, make sure to stop every node before backing up, not just one.

How to restore

  1. Stop the service.
  2. Restore the filesystem (config, data directory) and the database, preserving the original ownership and permissions.
  3. Start the service.

In a multi-node setup, copy the config file onto each node.