Bug #8994
closed
Two RRDDATA Sections in Restored Config Breaks Unit
Added by Chris Linstruth over 5 years ago.
Updated over 5 years ago.
Category:
Backup / Restore
Description
Had a user present a configuration backup with two rrddata sections.
Looked like this:
<rrddata></rrddata>
<rrddata>
<rrddatafile>
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.
I don't think this is limited to <rrddata>, any duplicate tag in the config will break imports, I've confirmed with <vlans> and <laggs> but I would think it applies to all duplicate sections.
- 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.
- Status changed from New to Feedback
- % Done changed from 0 to 100
Tested restoring the original problematic config.xml. It did restore successfully but there was no rrddata in the result after reboot.
- 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.
There was no rrd section in the resulting configuration at all.
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.
- Related to Bug #13132: Multiple ``<sshdata>`` or ``<rrddata>`` sections in ``config.xml`` lead to an XML parsing error during restore added
Also available in: Atom
PDF
Updated by Paighton Bisconer 
Updated by 
Updated by