RRD RAM Disk Backup/Restore
-
When backing up and restoring RRD for the RAM disk what is the purpose behind backing up and restoring as XML by using rrddump and rrdrestore rather than the RRD files directly?
-
An XML dump from rrdtool is architecture-independent, so it can be stored from 32-bit and restored to 64-bit or vice versa. That's how it's stored in the config.xml backup when the option is enabled also.
-
Thanks Jim. So is there a use case for doing the rrddump in the reboot/shutdown/periodic backup for ram disk instead of the *.rrd files directly? Would make that process cleaner, and straight forward without the rrddump.
-
I seem to recall it was done for safety reasons, it was easier for rrdtool to recover partial data/files from xml than the raw rrd, but I might be misremembering that.
Might have also been that the backup function was re-used so it was the same, rather than having two different means of backing up rrd depending on the context.
I'd have to go digging through the code for a better answer, but ultimately it seems like using dump/restore is the more proper way rather than copying the binary files around.
-
Thanks Jim. So is there a use case for doing the rrddump in the reboot/shutdown/periodic backup for ram disk instead of the *.rrd files directly? Would make that process cleaner, and straight forward without the rrddump.
Wouldn't be a good idea. That's a lot of processing for no reason in that case. It's fast and low-resource to copy the rrd files, doing a dump and restore chews up CPU and RAM. In the past, at times enough RAM that it runs an ALIX out of RAM and kills off the process. Good chance of data issues on low RAM systems if you did a dump on every shut down and restore at boot up.
-
@cmb:
Thanks Jim. So is there a use case for doing the rrddump in the reboot/shutdown/periodic backup for ram disk instead of the *.rrd files directly? Would make that process cleaner, and straight forward without the rrddump.
Wouldn't be a good idea. That's a lot of processing for no reason in that case. It's fast and low-resource to copy the rrd files, doing a dump and restore chews up CPU and RAM. In the past, at times enough RAM that it runs an ALIX out of RAM and kills off the process. Good chance of data issues on low RAM systems if you did a dump on every shut down and restore at boot up.
That's how it's currently being done. So should it be changed? Just tar the *.rrd files and do away with the rrdtool dump at shutdown and rrdtool restore at boot up?
In the ram disk management commit/pr submitted it should be pretty easy eliminate the rrdtool dump/restore on shutdown/boot up.
