The selected file /tmp/fileo3xhV1 could not be uploaded, because the destination sites/default/files/css/css_a91cd284035e73ba34d112bfed2f5a16.css is not properly configured.
  The selected file /tmp/filefQyJ2O could not be uploaded, because the destination sites/default/files/css/css_de1aa27776f1462d2b0d83a80ce4b92d.css is not properly configured.

Data History Tracking refers to the need to maintain a history of changes to a particular Field or set of Fields.

There can be many reasons why a builder will initiate a tracking mechanism for changing data. This could include anything from simple reporting needs, to a perceived need for security, to user-stamping, to a regulatory requirement such as Sarbanes-Oxley or HIPAA.

Depending on the nature of the changing data, there are a variety of simple best practices that can be followed.

Method 1: Single Field history tracking. When only a single Field's history needs to be tracked, it is easiest to simply enable “Field history tracking”, a setting found on most Field Types.

Method 2: Multiple Field history tracking. When a variety of Fields about an Item all can change and need to be tracked simulataneously, it is often best to move the storage of those Fields off the Item itself, and on to a related Item or Relationship. This way, each time a change is made, a new related Item is created, and all of the current values are stored on the most current Item. In this instance, it is simple to autonumber or date stamp the creation of the related Item if a chronological sort order is required.