This is how RRD is keeping track of the time-adjusted value for the step period.
You last stored a value, 60, at time 1360341382. Your step is 300, so your last RRD aggregation time was 1360341300, 82 seconds ago. Your previous value was also probably 60, given how constant you said these fan speed are, so RRD considers that since you stored 60 previously and you stored 60 at 1360341382, for the 82 seconds between 1360341300 and 1360341382, the value was always 60. 60 * 82 is 4920, the value you see stored.
Why does RRD do this? Well, if it wants to know what the average value is for that 82 second period, all it has to do is divide the value by the number of seconds to get 60. If you come along later, at 1360341464 (82 seconds later to make the math easy) and store the value 50, RRD will add 55 * 82 (55 because it considers the average for this 82-second period to be halfway between 60 and 50) to this value and store it. Now you'll have 9430 for the first 164 seconds of the aggregation period. If RRD wants to show you the average for the 164 period, it just takes 9430 and divides by 164 to get 57.5.
Since RRD aggregates on step boundaries, to make its life simple, it just creates a stored value for the aggregation period (in this case, 300 seconds). It will take whatever value it has saved up for the 300-second period and divide by 300. That will be the average for the step, and that's what gets stored and used for larger aggregations. The value field there is the intermediate value it uses to hold the time-weighted total it can use when it hits the next step boundary. This is an optimization to make aggregation work faster.
