Backing up rrd files on file system with noatime

[foobar2devnull]

Hi guys,
I am a bit confused on how to backup a Linux server running Zenoss. I need to backup RRD files on a noatime file system. Seeing as how an RRD file do not change is size over time and seeing how the access date is not refreshed due to the noatime flag, can the files be backed up?

The following documetation seems to say this can not be done if I understand correctly.

I did the following tests knowing that the RRD file is updated ever 5 minutes or so. We do an incremental backup on a daily basis that we keep for 30 days.

1. | 07/04/2016 10:53:53 16.00 KB A /opt/zenoss/perf/Daemons/PRA
2. | 10/20/2016 08:47:52 34.60 KB A /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
3. | 10/20/2016 08:39:09 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
4. | 10/17/2016 15:39:02 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
5. | 07/04/2016 10:53:53 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd

I ran two manual backups (2,3) and something is Zenoss was done that caused the RRD file to be recreated (4).

So my questions are:

1. Can TSM backup a file that does not change in size and where the access time does not change?
2. How come a manual incremental backup does backup the file but not a scheduled one? (# sleep 300 && dsmc i /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd)
3. What alternatives would you recommend? The partition is on an LVM so would an image backup be worth considering?

Thanks for your help.

 

[marclant]

Can TSM backup a file that does not change in size and where the access time does not change?

In regards timestamp, TSM only looks at the modified time, not the accessed time. Otherwise all read files would be backed up. I'm assuming you meant modified. TSM looks at multiple attributes of the file to determine if it changed. Check this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21320696 While it's for the opposite problem, you can use the tracing suggested in there to see if any of the attributes have changed.

How come a manual incremental backup does backup the file but not a scheduled one? (# sleep 300 && dsmc i /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd)

They behave the same way. This must be a situation where during the manual backup, a file appeared changed, but not in a schedule. Also, what's the schedule action, option and objects from the dsmsched.log, just to confirm it's doing the same as the manual backup.

What alternatives would you recommend? The partition is on an LVM so would an image backup be worth considering?

You could do a selective backup which will backup the file regardless if it changed or not.

1. | 07/04/2016 10:53:53 16.00 KB A /opt/zenoss/perf/Daemons/PRA
2. | 10/20/2016 08:47:52 34.60 KB A /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
3. | 10/20/2016 08:39:09 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
4. | 10/17/2016 15:39:02 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd
5. | 07/04/2016 10:53:53 34.60 KB I /opt/zenoss/perf/Daemons/PRA/zenjmx_queuedTasks.rrd

I ran two manual backups (2,3) and something is Zenoss was done that caused the RRD file to be recreated (4).

Every time you backup a new version, the previous becomes Inactive (I). This would tell me that this file in question was backed up 4 times. So before your 2 manual backups on October 20, you had a previous successful backup on October 17 and one on the 4th of July.

 

[foobar2devnull]

The trace was a big help and it turns out rrd files where not the problem, just cross team communication.

Thank you very much for your help!