Manage system backups

As with any application, it is important to ensure that backups are performed regularly. Depending on what features you have configured, and what other configuration you’ve changed, you should take backups from all areas so that you can restore everything in case of a failure!

This may include the Application Server’s database, configuration files, certificate stores, file system components and more. Best practice is to keep these backups on a different machine (preferably at a different site) so that if there’s a failure in your main server room or at your cloud hosting provider, you can recover from your backups.

System-wide backup

Before you dive into any big changes on your PaperCut server, like an upgrade, migration, or even a major tweak to your settings, we highly recommend doing a full system backup.

Think of this comprehensive backup as your safety net! It’ll grab everything from your operating system, all your PaperCut files, configurations, data, and even the internal database. That way, if anything unexpected pops up, you’ve got a handy recovery point to get things back on track.

Preparation

Before taking a snapshot or VM backup, ensure the following:

Stop the PaperCut services:
- Application Server Service
- Print Provider Service
For more information on how to do this, see the article Stopping and Starting (Restarting) PaperCut Services.
Confirm that no upgrades, patches or print jobs are currently running.
Ensure there is sufficient free disk/storage space for the snapshot or backup image.

Using your hypervisor’s snapshot or backup feature

If your PaperCut server is a virtual machine, you can easily use your hypervisor’s snapshot or backup tools to capture its state!

For comprehensive guidance, we recommend checking out the vendor’s documentation. They’ll have the most up-to-date instructions for creating application-consistent VM snapshots or exports, as settings can change.

Using external virtual machine backup software

When it comes to backing up your virtual machines, especially when using dedicated VM backup tools. We recommend checking out your vendor’s specific documentation. Each tool has its own unique setup, scheduling, and retention configurations, so their guides will have all the exact steps you need to get things just right in your environment!

Verifying & testing the backup

Once your snapshot or backup is all done:

Check the status in the hypervisor or backup console to confirm everything looks good.
Double-check that all your VM’s virtual disks and PaperCut folder are included in the backup.
Carry out a restoration of the backup job in accordance with your organization’s protocol. Try a test restore in a safe, non-production environment, just to be sure it’s working perfectly! Ensure this test environment does not have access to your production environment.
Once you’ve given it the all-clear, go ahead and restart those PaperCut services and make sure everything’s back to normal (like logging in, accessing the PaperCut admin interface, and printing without a hitch!).

Great job! If you’re using an internal database, you’re now ready to move forward with your PaperCut server upgrade, migration, or any changes to your PaperCut settings. If anything unexpected happens, you can simply use your VM snapshot or full VM backup to get your system back to where it was. If you’re using an external database, just keep scrolling to the next section for how to back up your external database.

Performing a test recovery helps you estimate how long to set aside for the upgrade, and gives you a good idea of how much time you’ll need if you happen to roll back.

To learn more about the upgrade process, see here . For information on PaperCut server migration, see here . For details on external database upgrades, refer to here .

Database backup

The PaperCut NG/MF Application Server database holds all the ‘meta data’ for your print environment. It includes user configuration, costs, quotas, print logs, audit logs, printer configuration, system configuration and lots more. Without a database backup you would need to set up everything from scratch - including re-syncing your users, provisioning user quotas, setting up shared accounts, configuring printers and re-setting-up feature settings.

PaperCut NG/MF includes a built-in database export that saves the state of the database to a file. This functionality complements (not replaces) a good system-wide backup process. The export is stored in the industry standard XML format and compressed using the standard ZIP format to reduce disk space on the server and your backup medium. The use of these open standards ensures that your data is always available and accessible.

As PaperCut NG/MF is centrally managed - the only database that requires backup is on the Application Server. Secondary print servers and Site Servers do not require a database backup.

PaperCut NG/MF makes managing export backups simple by automatically performing a weekly export. Export backup files are placed in the following directory:
[app-path]\server\data\backups

The weekly exports are performed at 20 minutes past midnight on Sunday morning (or as otherwise defined by the schedule.weekly config key. See Using the Advanced Config Editor to find out how to change config keys.)

Tip

In accordance with backup best practice, back up the above directory regularly to offline media (for example, tape, CD or remote server). This allows the data to be restored in the case the server hard drive is corrupted.

You can find an example backup script called copy-backups-to-remote-server.bat at [app-path]/server/examples/scripting/batch/. It can help administrators automate the process of maintaining an off-disk copy.

On larger networks, you might want to perform export backups more frequently than the in-built once-a-week period. Use the server-command tool to execute the export task at other times. Simply write a script (for example, batch file) to execute server-command perform-online-backup. Schedule the script to run at the desired intervals. More information on server-command is available in Server commands (server-command).

Performing an online database backup (export)

In addition to the automated weekly exports, you can also manually initiate a database export. This might be useful to back up the system database before performing an upgrade. To perform a manual export:

Select Options > Backups. The Backups page is displayed.
Click Export Now. A window is displayed showing the export progress and the location where the export file is saved.

Restoring a database backup (import)

There are a number of situations when it might be necessary to restore a database, including the following:

A hardware or system failure requires you to rebuild the server and reinstall PaperCut NG/MF.
A new print server was purchased and PaperCut NG/MF is being moved to a new server.
To import data into an external RDBMS (see Deployment on an external database (RDBMS) ).

To restore from an export file:

Locate a previous export file.
Stop the Application Server service. (See Stop and start the Application Server ). The database cannot be in use when performing the restore, so the Application Server needs to be stopped first.
Open a command prompt. On Windows systems, this might need to be specifically elevated to run with administrator privileges, even if you are already logged in with an administrator account. Change to the server binaries directory. On a Windows system, the directory location is [app-path]\server\bin\win\.

Note

You must run the command prompt as an Administrator. In the Windows Start menu, right-click Command Prompt; then select Run as administrator.
Re-initialize the database back to an empty state by typing the following:
```
  db-tools init-db -f
```
Run the import process by executing the following. Be sure to replace the example backup path between the " " with your specific backup path.
```
  db-tools import-db -f "<directory\backup-file-name.zip>"
```
For instance, if the backup directory and file is c:\program files\PaperCut\backup\backup.zip, the command will be:
```
  db-tools import-db -f "c:\program files\papercut\backup\backup.zip"
```
(Or, /ng-mf/db-tools on some systems. See Database tool (db-tools) for more information on using db-tools.)

For macOS/Linux platforms, there are some extra steps listed below

On macOS and Linux, you need to ensure that the proper permissions are applied to the backup file, and that the backup file is relocated into the PaperCut MF or PaperCut NG directory (so that the papercut user account can access the backup zip file):

a. Ensure the proper permissions are applied for access to the file:
```
  chown papercut:admin \path\to\backup\backup-file-name.zip
```
b. Move the file into the PaperCut MF or PaperCut NG root directory:
```
  sudo mv /path/to/backup/backup-file-name.zip /Applications/PaperCut\ MF
```
c. Run the import-db command as detailed above:
```
  /ng-mf/Applications/PaperCut\ MF/server/bin/mac/db-tools import-db -f /Applications/PaperCut\ MF/backup-file-name.zip
```
After the import has completed, restart the Application Server service (see Stop and start the Application Server ).

Performing an offline database backup (export)

Performing an online backup (as discussed above) is a simple and convenient process, but it is sometimes necessary to perform a backup when the Application Server is not running. For example:

To integrate into your existing backup procedures, it might be necessary to write a script or batch file to perform a backup at a known point in time
When it is necessary to guarantee that the backup captures all the data. Performing an online export while the system is in use can modify data after the export is complete.

To perform an offline backup:

Stop the Application Server service (see Stop and start the Application Server ). This ensures all data will be captured.
Open a command prompt. On a Windows system change to the following directory:
```
  [app-path]\server\bin\win\
```
Run the database export process by executing:
```
  db-tools export-db
```
(This creates an export file in the system backups directory and the filename named with a timestamp.)

The export command has additional options that allow you to specify a different directory or filename. See export-db Command for more details.

Database backup retention

Database export ZIP files located in [app-path]\server\data\backups are retained for 30 days and then automatically deleted. This retention period can be adjusted on the Options > Backups page under the “Keep exports for … days” setting.

The retention period is automatically extended if exports are not performed regularly, such as when automatic exports are temporarily disabled or scheduled exports are skipped due to a system outage.

Older export ZIP files are not deleted until a sufficient number of new exports have been performed. The latest export file is always retained, irrespective of its age.

File system backup

Earlier, we talked about doing a full system-wide backup. If, for any reason, you’re unable to perform a snapshot or full VM backup of your PaperCut server, here are the key files and folders you absolutely need to back up:

[app-path]/server/server.properties
[app-path]/server/security.properties
[app-path]/server/data/
[app-path]/server/custom/
[app-path]/server/lib-ext/
[app-path]/providers/
[app-path]/client/
[app-path]/job-ticketing/

However, it’s simpler and safer to ensure you have regular backups taken of the full installation directory (e.g. C:\Program Files\PaperCut MF\). Make sure that you keep your backups in a different location, so if you lose the cloud instance or server that the App Server is running on, you can restore it from the backups kept elsewhere.

If you’re using PaperCut Mobility Print, you should also ensure that the Mobility Print directory is backed up. This is normally outside of the Application Server directory (e.g. C:\Program Files\PaperCut Mobility Print\).

Print Archive file backup

Print Archive files store images of all your organization’s printed documents. If your company uses the Print Archiving feature, backing up these files ensures a complete history of printed output, which is great for compliance and audits. Without a backup, you could lose these valuable records forever if anything goes wrong, such as data corruption or a system hiccup. So, it’s a good idea to keep them safe!

By default, the print archive is stored in:
[app-path]\server\data\archive

It’s important to note that Print Archive is stored at the file system level, not within the database. Therefore, it is not included in the database exports detailed above. We recommend incorporating part or all of Print Archive into your existing backup processes.

As PaperCut is resilient to partial restoration of the Print Archive, you might want to back up only a month or two worth of archives. There is a README.txt in the archive directory that explains more about partial backups and the directory structure layout.

Print Deploy configuration backup

Print Deploy configuration files are essential for managing and distributing print queues across your network. These files contain all the settings, drivers, and deployment rules for your Print Deploy clients. Backing them up ensures that if you ever need to restore your PaperCut server, migrate to a new one, or recover from data loss, you can quickly redeploy your print environment without having to manually reconfigure every print queue and client setting from scratch. This saves significant time and effort and maintains consistent printing services for your users.

The files created and used for Print Deploy are not included in the nightly PaperCut NG/MF backups. You need to set up your own backup procedure for the Print Deploy configuration files. Back up the following files:

Windows Application server

  <install path>\providers\print-deploy\win\data\

Mac Application server

  <install path>\providers\print-deploy\mac\data\

Linux Application server

  <install path>\providers\print-deploy\linux-x64\data\

Here’s your answer

Did this solve your issue?

Oops!