Backups and In-Place Upgrades

Hi Everyone,

For the past couple of weeks, we’ve been working on the ability to perform backups of the Passwordstate database, and all the web files, right from within the Passwordstate application. In addition to this, and it’s been a long time coming (sorry), you can now perform in-place upgrades of Passwordstate – no longer do you need to uninstall and re-install Passwordstate every time there’s a new build released.

First we’ll start with the backups. You have the option of performing manual backups whenever you need, or you can set a regular schedule and let them run themselves. You have the following options available to you:

Backup Settings

  • How many backups to keep on the file system
  • The path to where you would like to store the backups (ideally should be stored on a different location other than your Passwordstate web or database server)
  • Username and Password required for the backup (we’ll explain what permissions are required further below)
  • Whether you want to enable a regular set-and-forget schedule for the backups to occur
  • And finally, what time you would like the scheduled backups to begin, and how often you want a backup to occur.

Couple of screenshots to show you the status of backups, and also the Settings screen:

Backup Permissions
To allow backups to work through the Passwordstate web interface, you will need to specify an account (domain or Windows account), which has the following permissions:

  • Permissions to write to the Backup path you’ve specified
  • Permissions to stop and start the Passwordstate Windows Service on the web server
  • Permissions to write to the Passwordstate folder.

In addition to this, you must configure the SQL Server service to use a domain or Windows account which has permissions to also write to the Backup Path. To do this, you need to open the ‘SQL Server Configuration Manager’ utility on your database server, click on ‘SQL Server Services’, and the specify and account as per the next screenshot:

 

In-Place Upgrades
A prerequisite to being able to perform in-place upgrades in version 6, is to ensure your backups are configured and working correctly. If they aren’t, you will not be able to perform in-place upgrades. There are to main processes for an upgrade:

Upgrade Web Files
Prior to performing the upgrade of the database, the following occurs:

  • Passwordstate Windows Service is stopped
  • Compresses and backup all the web files
  • Backup up the database
  • Download the latest build from the Passwordstate web site (there is an option to manually download the upgrade file, if for whatever reason Passwordstate is unable to do it itself i.e. proxy issues)
  • Extract the latest build to a temporary folder
  • Overwrite all the files, and clean up any old files
  • Restart the Passwordstate Windows Service.


Upgrade Database

Once all the web files have been upgraded, you will be logged out of Passwordstate automatically, at which time you can log straight back in and finish the upgrade of the database. The reason the log out is required, is because modifying files in a IIS web site can cause sessions in IIS to be disrupted (ended).

We apologize it’s taken so long to come up with a better upgrade procedure, but as soon as version 6 is released, it should make upgrading to new builds a whole lot easier.

Regards
Click Studios

Comments

  1. Will there be an easy upgrade path from version 5 to version 6?

    • support says:

      Hi Matt,

      Yes, the upgrade will work from V5 to V6, and will follow the same process you’re use to for upgrades. Once you’re on V6, the inplace upgrades will make future upgrades a lot easier.

      For the V6 upgrade, we may need our customers to run one SQL Script manually, as we need to rename the database from passwordstate5 to passwordstate, as we should never have really used a version number in the database name to start with.

      Regards
      Click Studios

  2. This sounds great. How does it work for customers with the HA module? Currently that requries you to break SQL replication, upgrade one instance, then upgrade the other before re-establishing replication.

    Is this new upgrade process HA aware such that it does that process for you?

    • support says:

      Hi Paul,

      If there is a database schema change in the release, then you will still need to break the SQL replication manually – unfortunately there’s nothing we can do about this, as you cannot replicate data and change the schema at the same time.

      In each of our upgrade instructions we document which Builds changed the Schema, so it won’t be required every time.

      Regards
      Click Studios

Speak Your Mind

*