# Restoring from backup

## How do I restore a PaperCut database file?

Note: To make sure the files are not in use at the time of restoration, remember to stop the PaperCut Application Server service before getting started.

### PaperCut (Internal Database):

• Copy and paste (yes, really).
Replace the existing contents of the directory below with the contents of the same folder from your latest off-disk backup (e.g., your backup software):
[app-path]/server/data
• Restore from PaperCut’s automatic DB export
Alternatively, PaperCut performs an automatic weekly database export, which is a form of backup. You can leverage these weekly exports to restore to a specific a point-in-time. The exports are in the following directory:
[app-path]/server/data/backups
Again, you may need to restore your latest point-in-time database export file from your system’s off-disk backup system. In any case, the files all end in a zip extension and have names that include the date and time to help you select the most recent export. Use the db-tools binary to restore the files as described in the excerpt from the manual below:
1. Locate the most recent DB export file by browsing to [app-path]/server/data/backups.
2. Since the database cannot be in use when performing the restore, stop the Application Server service.
3. On a Windows print server, open an elevated command prompt the change to the server binaries directory C:\Program Files\PaperCut NG or MF\server\bin\win\. On macOS, the server binaries are in /Applications/PaperCut NG or MF/server/bin/mac/ and on Linux in /home/papercut/server/bin/linux-x64/.
4. Re-initialize the database to an empty state by typing the following: db-tools init-db -f. On macOS and Linux, run the command like any executable file: ./db-tools init-db -f.
5. Run the import process by executing the following: db-tools import-db -f “C:\path\to\backup\backup-file-name.zip”. As above with macOS and Linux, don’t forget to prefix the command with dot slash.
The process warns that an import deletes the existing database data before proceeding, so choose yes to continue.

I used the following manual pages to adapt the instructions above:

and

### PaperCut (External Database):

An externalized database stores all PaperCut data except for the following items:

• The Print Archive data (see below)
• The database connection details

Instead, these settings are in the [app-path]/server/server.properties file. If the Application Server fails, all data is still safe in the external database. Merely re-installing PaperCut, completing the configuration wizard, then pointing the server.properties file to the existing external database restores all settings and data.

If your database crashes, follow your database’s recommended restore procedure. Again, PaperCut does maintain it’s own point-in-time database exports (see above) in the directory:

[app-path]/server/data/backups

## How do I restore PaperCut Print Archives?

### PaperCut by default stores the Print Archive data in:

[app-path]/server/data/archive
Your existing backup processes can help to restore this directory, and, due to designed resilience, you can do this wholly or in-part allowing for backups of one or two months worth, for example. The README.txt in the archive directory explains more about partial backups and the directory structure layout.

## How about back up with Print Deploy?

We have this documented in the Print Deploy Help Center which you can find over here.

Categories: How-to Articles, Backing up and Restoring, Databases

keywords: crash, restoration, back-up, point-in-time, export, image, storage