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):
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:
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:
Locate the most recent DB export file by browsing to [app-path]/server/data/backups.
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/.
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.
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:
An externalized database stores all PaperCut data except for the following items:
The Print Archive data (see below)
The admin password (for security reasons)
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:
How do I restore PaperCut Print Archives?
PaperCut by default stores the Print Archive data in:
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.
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.