PRESERVATION RECORD
The preservation and retention-hold chronology for the Hostinger case, including what was requested, what was recorded and what remained unconfirmed.
Preservation is tracked separately because a request, a support acknowledgement, an internal instruction and a technical hold actually applied are different states. The record also contains an earlier August preservation request that predates Hostinger’s stated August 21-22 quarantine-byte expiry, creating a chronology that must be shown separately from the September recurrence.
August 19: preservation was requested while the dispute was active
The August 19 email expressly requested preservation in connection with GLB-247793 and the missing customer-facing escalation conversation. The same exchange also documents erroneous routing to unrelated ticket #125522 and an immediate correction asking Hostinger to keep the matter under GLB-247793 and record the preservation request there.
August 27: Hostinger described two different retention windows
Hostinger said the retained event and scan records were subject to a standard 30-day period and that steps had been taken to preserve them beyond September 6. Separately, Hostinger said the original pre-cleanup bytes had been automatically deleted on August 21-22 under a 14-day quarantine policy. Preserving the event record and preserving the original quarantined bytes are therefore distinct questions.
The August preservation chronology contains an unresolved conflict
A September 3 Hostinger response said the original copies had been deleted under the fixed retention period before the preservation request was received. The archive nevertheless contains the August 19 preservation request covering scanner logs, Event IDs and related case records. That August 19 wording did not expressly name the original quarantine object or pre-cleanup bytes, so the case file records an unresolved timing-and-scope question rather than claiming that an explicit hold on those original bytes had already been confirmed.
September 11: what was requested
The September 11 request sought preservation and a retention hold for the new manager.php event records and for any retained original or quarantine object associated with the September removal.
What Hostinger confirmed was recorded
Human support stated that the explicit request had been forwarded and recorded in complaint #137820 at a Hostinger-stated time of 13:04. This establishes the complaint record of the request, not the technical application of a hold.
What remained unconfirmed
At 14:47 CEST, support said actual hold application had not been confirmed. At 17:40 CEST, the latest preservation statement in the supplied archive still did not confirm actual hold application, an internal hold reference or extended retention for any retained original or quarantine object.
The 17:02 and 17:33 conflict
At 17:02, a human agent said the explicit non-expiry instruction had not yet been sent. At 17:33, the same agent said it had been sent at 14:35 UTC, equivalent to 16:35 CEST. The stated send time therefore predates the message saying it had not yet been sent. Both statements are preserved as given; the available material does not establish why they conflict.
What the case file does not claim
The current record does not establish that the September object was destroyed after the request, that Hostinger refused preservation, or that any person intentionally allowed evidence to expire. Those propositions remain outside the factual claims published here unless new documentation establishes them.
September 15 — direct verification remained pending
At 13:33, Hostinger said it still could not confirm whether a preservation hold had actually been applied to the September 10 records or original/quarantined object. It said the question required internal verification and promised a confirmed Yes-or-No answer with the applicable date and reference.
September 15 — preservation renewed; object status still not verified at 14:48
At 14:39, the customer expressly renewed and continued the preservation request. At 14:48, Hostinger acknowledged that renewed request.
At that cutoff, Hostinger said it could not yet confirm a verified Yes-or-No hold answer or responsibly confirm the existence, expiry, deletion status or retention period of the relevant records or object. The public record therefore marks those points as unverified rather than inferring either preservation or destruction.