Two RRDDATA Sections in Restored Config Breaks Unit
Had a user present a configuration backup with two rrddata sections.
Looked like this:
The configuration uploaded but the config parser did not like it:
Fatal error: Uncaught Exception: XML error: RRDDATA at line 2179 cannot occur more than once in /etc/inc/xmlparse.inc:87 ...
Removing the empty rrddata section allowed the configuration to be uploaded and applied successfully.
It was an 18.0 (2.4.3_1) backup.
#2 Updated by Jim Pingle almost 2 years ago
- Target version set to 2.4.4-p1
The rrddata case is special because of the way the backup process injects the data into the config before serving the backup to the user. The others could only happen by manual duplication.
I pushed a fix to avoid the problem case on both backup and restore.
#5 Updated by Jim Pingle almost 2 years ago
- Status changed from Feedback to Resolved
Did you look far enough back in time on the graphs to see data from the date before the backup was taken?
I took a backup with RRD, edited in the bad blank tag, reset RRD so everything was blank, then restored. The RRD data from the backup was restored as expected. Looks good here. I had to set the time span on the graph to a week to see anything meaningful in the graphs after restore since that was the last obvious spike.
#7 Updated by Jim Pingle almost 2 years ago
It should be removed by the restore as its last act, since the data is taken out of config.xml and converted back into the RRD data file format expected by
rrdtool. Checking the graphs is the best way to reliably know if the restore succeeded.
Only the backup should contain
<rrddata> tags, they should never been seen in a live config.