Follow

Local Settings

On the Settings->Local tab you can change where new backup accounts are created, where metadata is stored and backed up, how many simultaneous backups threads are available, configure advanced security settings such as whitelisting and blacklisting, and even customize what to do with registration and credit card data (using the two .BAT files which are auto-created as templates).

At installation time, meaningful default settings were created for the locations specified on this tab, however we recommend that you change are certain your are happy with where “New accounts” backups are stored and where the metadata files (those indicated with red marker) are backed up to.


 Please note that clicking on the “Save Settings and Restart Service” button will disconnect all connected backup and restore users, but they should then re-connect automatically and resume where they left off.  (You can see which users are connected on the Dashboard->Transfers tab).

The meaning of each of these fields is as follows:

New accounts in folder

As each new account is registered, a sub-folder with the account name will be created inside this folder.

 Please note that the user the service runs as must have permissions to read and write to this folder.  If this folder is on a network share or mapped drive please read our article here.

 You can move backup accounts later on the Dashboard->Accounts tab.

Account DB file

This file contains backup account credentials as well as backup/restore status and history (used in Dashboard).  It is critical you do not lose this file (nor the CSV file described later if you wish to recover user passwords).  If you implement load balancing, this file can be placed on a network device and shared by multiple backup servers BUT is must be resident on an NTFS file system, or other Microsoft certified file system which properly supports Microsoft Windows file locks.

 Linux NAS devices using SAMBA do note adequately implement WIndows file locks so DO NOT place WSBU.db on such as device/share!

Credit Card BAT file

A .BAT file to run during client registration when credit card data is sent to this server.  This command is run within a Command shell and it is passed numerous parameters as described in the default WSBU_CC.bat file which was created at installation time.  When you create a white label backup client you specify whether credit card data is to be captured in the installation wizard, and if it is to be captured whether its optional or required and what types of credit cards you accept.  You also specify at white label build time what URL supporting https you wish to use to capture and take action on the credit card data.  We supply a template PHP file which you can enhance to make connections to a credit card processing gateway such as authorize.net.

Alternatively you can have credit card data sent to this WholesaleBackup server which will invoke this WSBU_CC.bat file.  The default WSBU_CC.bat file is well documented so you can do whatever you wish with the incoming credit card data including storing it in a file or database or invoking some other application.  This file will return a billing token back to the client which will be present in the Dashboard->Storage table and output reports so you can associate your software clients with specific billing accounts.

 Be absolutely certain you are adhering to PCI compliance standards when capturing, processing, and saving digital credit card information.  More information on PCI compliance can be found at https://www.pcisecuritystandards.org

Registration BAT file

A .BAT file to run after every account registration/re-registration.  This command is run within a Command shell and it is passed numerous parameters as described in the default WSBU.bat file (which are also found in the WSBU.csv file).

 By using this feature you can extend the Registration Service to perform custom operations when accounts are registered.

Registration CSV file

Location of CSV file containing detailed account registration information. Note: If a client has selected that they don’t want their password backed up then that user’s password will not be written to this file. Similarly, if “Write passwords” is checked then passwords will be written to the CSV file. These options allow compliance with various security standards. The easiest configuration from a support standpoint is to have the passwords available as users do lose or forget them.

 To state the obvious, please be sure that only the user the Registration Service is running has read privileges to this file as it may contain passwords.

Service LOG file

The log file for the Registration Service.  Please note that if “Write to System Log” is checked then duplicate entries will be written to the Microsoft Windows System Event log.

Certificate (.PEM) file

At installation time an unsigned SSL certificate file was created which is valid until 2028.  You can move this file or use your own by changing the location here.  We reccomend that you purchase a publically signed SSL certificate and replace this default PEM with the PEM for your public certificate.  For instructions on how to generate and use your own certificate please read this page.

Backup above files every ... hours to folder

Location and frequency of backups of the WholesaleBackup Server’s metadata files (on the “Local” tab of the GUI, these are preceded by a red asterisk *). These files should be backed up to an alternate drive from the originals and preferably to an entirely different computer if possible.

Check for new software releases every day and automatically...

 

When selected your server will stage upgrades to your clients to download at their next backup or restore.  The server will check for client upgrades every hour but will only stage them if the latest upgrade is at least 24 hours old.  Please note that at anytime you can manually stage upgrades on the Dashboard->Accounts tab using the "Upgrade Every Client's Software" button.

Number of threads to service backup/restore requests

The WholesaleBackup Server is transaction oriented and clients will connect to the Server to make registration, backup, and restore requests.  This setting allows you to configure how many simultaneous transactions can happen at any given moment.

 Please note that since the Server is transaction oriented you can have more users than the # of threads running backups and restores at any given moment. Since each client connection is a series of many transactions it is possible to have many clients alternating transaction threads constantly.  We recommend using multi-core processors to optimize thread performance. 

Default all newly registered clients to use status:

When a new backup account or computer is registered with your server, it will be assigned the default status you specify here.  You can change the status of accounts after registration on the Dashboard->Accounts tab.

Prevent registration of these brands

A ‘;’ separated list of brands to prevent from registering.  If empty, then no brand is black-listed.  Please note that black-lists have priority over white lists.

Only allow these brands to register

A ‘;’ separated white-list of brands to allow to register. If empty and not black-listed, then any brand can register.  Please note that black-lists have priority over this white list.

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk