How can I move the historic data of one sensor to another ?

A word of caution

This post contains procedures that are not recommended by Paessler. Please note that we provide this information without warranty and that we cannot officially support you with this. Please make sure you keep a proper backup of your configuration and data files.

While it's not directly possible within PRTG, I have found a weird sort of workaround that probably doesn't work for every situation.

In my case, we've had problems with Windows network interfaces getting a new SNMP interface index when the server reboots and for some reason, PRTG doesn't recognize the change and either get's a "SNMP no such name" error or worse, starts putting one interface's data into another interface's sensor.

The process is: stop the core service, edit the "PRTG Configuration.dat" file and locate the sensor in question; change the index ID to the new one (learned through a manual snmpwalk process); save the file; restart the core service. Note: This only works if the old and new sensor are on the same device.

In essence, PRTG is now collecting from a "different" interface but still logging the data to the old sensor. I'm sure this process could be modified to move data from one device to another but that takes more XML-jitsu than I have.

I would like to add some facts about PRTG's internals here:

PRTG stores historic sensor data for all sensors of one device into one file per day in the monitoring database folder. So the historic data is always stored with the device and you can not migrate it to a different device or sensor.

Jim Kirby's answer to this question is the "hacker's solution": Basically you delete the old sensor, create a new sensor, stop the core server, replace the new sensor's id with the id of the old sensor (the old sensor MUST BE DELETED before that) in the XML configuration file and restart PRTG. Jim correctly states that this is only possible if both sensor reside on the same device.

hello,

Is it now possible, in version 9.2, to move the old data ?

regards Marco

Dear Marco, not that is not possible in 9.2. To be honest this is not planned.

Would this be the correct place to request this as a feature? I know this lack of functionality has already caused me some disappointment with PRTG, which is odd since I usually tell everyone how great it is.

The obvious reason is that, regardless of how PRTG is designed internally, websites and other services do move from server to server (device to device). This is a common scenario played out in IT shops around the world everyday. And with virtual machines becoming the standard, it will be even more common.

I ask that you seriously consider this as a future enhancement. Since PRTG is a mature product that already does every type of monitoring possible, I can't think of a better feature to offer your users than this.

John, this would be the correct place (or send us feature requests via email to [email protected]), but I'm afraid for this particular one, there are no plans to implement this. Sorry.

I understand Torsten. I work for a software company and I know how these decisions are made.

What's upsetting it that I know for a fact that previous versions of PRTG could do this (It was a simple drop down list in the sensor settings). It's unfortunate that a design decision was made at some point that caused the loss of this functionality for your users.

Having a way to do this would be a great feature. +1 from a feature request standpoint. I use some products that have different OIDs with different software versions. I realize if I had been smart enough to manually add the OIDs in the first version I could just edit the OID, but I don't see a way to do that when I've imported the oidlib.

Has being able to move historic data to a new sensor already become a feature on versions 14+?

Thanks.

Vicky Barraza

Moving sensor data from one sensor to another is not possible in PRTG 14, and to be honest, is not planned either. You can clone the old sensor and pause it to keep its old data. That would be the suggested solution.