• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 6 replies
  • Subscribers 12 subscribers
  • Views 717 views
  • Users 0 members are here
Options
Related

Step by step guide for transferring Historian data to a new historian server.

Jakob Agustsson

Hi Historian specialists!

I feel there is really missing a proper step by step guide on how to completely transfer Historian data from a old historian server to a newly installed historian server on another machine.

Is there anyone that knows of a guide like that ?

I am upgrading from SP20 to SP23 including Historian 20 to 23.  The galaxy is the same but migrated to version 23 on a new machine

how i think it works:

1. Old historian server: export database via the import export function provided with historian software  OR do a backup of the runtime database within SQLstudio (sounds more complicated for unexperienced users)

2. After installation of historian 23 is complete on the new machine keep it in shutdown mode. (not sure about this one, since it doesn't completely create the folder structure)

3. Leave appengines/instances un-deployed on the new galaxy while historian is in shutdown.

4. Import the runtime database from the old version/machine either via export import function or SQL backup restore (again more complicated to do it in SQL).

5. Start the historian.

6. Deploy instances in new galaxy. Which makes the historian server create the first new history block.

7. stop historian and copy old history blocks between old and new server.

8. final step start the historian.

I am not sure if this is the way to do it, I would really appreciate any help Slight smile

thank you

rgds

Jakob

Parents
  • +1

    There is a Tech Note (see Article 000034301) published with more complete instructions. Though Historian 2023 R2 isn't mentioned in the Tech Note, the same steps still apply. Using the SQL database backup/restore is generally better as there is some information missing in the CSV-based export/import (e.g. tag groups, annotations, and Historian Client Web charts). It is included in those instructions, but there are few aspects that might be missed in your steps above:

    1. If the old/new server names are different, you'll need to tweak a few more things
    2. If you use the database backup/restore, use the Configurator to migrate the old database schema to the new one
  • 0 in reply to Elliott Middleton

    Hi Elliott, thank you for your help.

    managed to figure the transfer out. 

    Just to explain before I hit you with a follow up question.

    What I have now is two identical systems running the same galaxy structure. 

    old system SP v.20 and new system SP v.23 , both are on the same network but run independently of each other. 

    No SMS activated (will configure it when old system is removed, to avoid conflict between the old and new system)

    Instead if transferring the runtime database from the old system, I recreated it on the new server through deployment to the new historian, ( I could because it consists of the same tag names) I could then copy the history blocks from the old system.

    Final step to be able to query the data was copying certain files from the old historian support folder into the newest history block on the new historian server. 

    Both installations are running on the same Domain network all the same users and everything user access related the same. The admin account I used to install everything is the same.

    We use windows integrated login for all users that connect to the SQL database when adding a historian server in the historian client.

    What now remains and I have not been able to figure out...... 

    I need the SCADA users to be able to add the new historian server when they run the historian client.

    They are able to add the old historian server but not the new. 

    The "main" system platform admin account i use for installation and service works fine but not any others.

    I am pretty sure it has to do with the historian security settings in the configurator. Tried adding one user to test,  but it doesn't change anything.

    Any help would be appreciated! 

    regards

    Jakob

  • 0 in reply to Jakob Agustsson

    Sounds like the security change to add the one user wasn't picked up. That could be because the security is based on membership in a local Windows group and those are only refreshed upon a new login--if there is a cached login from before the change, that won't pick up the new group membership (a Windows "feature").

    If you know the only login is RDP, for example, you can "Logout" that session (not "Disconnect"), but there can be file share access and other cached logins that are harder to find and logout. The only guaranteed way to clear that cache and ensure all the current group memberships are applied is to reboot the Historian node.

  • 0 in reply to Elliott Middleton

    ok, will try that,

    Do I understand correctly that when a user is added to the historian security list in the configurator on the historian node. It adds the user to a local windows group that has the access needed.?

  • 0 in reply to Jakob Agustsson

    Yes. You can accomplish the same result using the standard Windows MMC snap-in (and other tools) for managing users, but the panel in the Configurator aims to simplify that experience. There are well-known groups for "aaAdministrators", "aaPowerUsers" and "aaUsers" with different rights. You can read more about those in the administrator docs. 

Reply Children
© 2024 AVEVA Group Limited or its subsidiaries. All Rights Reserved.