Resolved - This incident has been resolved. We have fixed the regression and removed corrupted files.

Additional update:

The incident caused some files under 1MB being written either by the CMS or by a manual upload (e.g. SFTP) to be corrupted. Those files have been purged. Their content is gone. The window of the incident began on the evening of June 29th Pacific Time (0300 UTC June 30th) and lasted until approximately midnight July 1st (0700 UTC July 2nd). As of right now affected files will show up in directory listings, but do not contain any content.

Two classes of files widely impacted were aggregated CSS or JS assets, as well as image thumbnails. If you are experiencing issues related to these assets, you should immediately flush all caches or otherwise trigger the regeneration of those files. Now that the file persistence layer is stable, they should perform as usual after being regenerated.

We will be conducting and communicating a full audit of corrupted files for all affected customers, as well as removing all errant references from directory listings. This will take some time, but work is already underway.

If you need to find out if a file uploaded or written by the CMS was lost, you can review recently added files via your WordPress or Drupal admin interface, and see if they are still available. If not, you should re-upload them if possible. This is the only path to restoring lost content.

Backups will not contain the missing files, but as a last resort restoring from backup is a way to get a site back to a previous stable state. For safety, you should use a backup from before 0300 June 30th (8pm PT June 29th). Restoring from backup disrupts a site, causing some downtime. For sites with a small content footprint, a restore to the live environment can complete in a few minutes.
To minimize downtime, you can individually import the elements of a backup to another environment (e.g. test) by copying the url to the backup elements and pasting it into the other environments “import” field. Once that workflow completes, clear your edge cache, test your changes, then use the content sync workflows to sync the db and files back over to live. Import via URL only works where the backup elements are under 500MB in size, but it will minimize the disruption in the live environment.
You can open a support ticket or engage chat for further consultation if needed.
Jul 2, 14:52 PDT