Xylora Studios maintains automated version control, database snapshots, and build archives across active development phases, handing off clean production packages upon delivery. Backup management is handled directly by the Technology department, covering studio-hosted environments and project code repositories.
Infrastructure and allocation of duties
Responsibility for backups depends on the project lifecycle and hosting ownership:
- In-development assets: While a project is actively built, the Technology department oversees all code commits, database states, and design file iterations. Code is tracked in private repositories, with database snapshots taken prior to major structural migrations.
- Studio-managed hosting: If your live site or application is hosted on servers provisioned and managed by Xylora Studios, automated file and database snapshots run on scheduled cycles.
- Client-managed environments: If your application is hosted on your own server, cloud account, or third-party web host, ongoing routine backups remain your responsibility unless an ongoing maintenance package has been formally agreed on the packages page.
- Creative assets: Source files, branding packages, and compiled design components are stored in internal cold storage following delivery sign-off, maintained by Operations & Client Services for reference.
Routine snapshots and archival stages
Our backup workflow follows three sequential phases:
1. Continuous version control: Every line of code written by the Technology department is pushed to branch-managed repositories. This ensures every individual deployment can be reverted to a preceding stable commit. 2. Staging snapshots: Staging environments are snapshotted prior to any database schema changes, CMS core updates, or structural refactoring. Should a migration fail, the staging environment can be reset to the pre-deployment state immediately. 3. Milestone and post-launch handovers: When a project reaches sign-off, a complete snapshot is generated. This includes compiled production code, raw design assets, and database export files. These archives are supplied to you or stored in our secondary vault.
Incident response and restoration workflow
If a data incident, code corruption, or accidental deletion occurs on a studio-managed environment, the recovery process runs through the following sequence:
1. Notice logged: Open a ticket using the Ask Xylo chat on this portal, identifying the affected environment and the nature of the issue. 2. Triage and assessment: The Technology department assesses the issue during working hours (Monday to Thursday, 09:00–17:00 GMT). First response targets sit within 24 hours. 3. Snapshot isolation: We identify the most recent known clean snapshot. If the environment is live and unstable, maintenance mode is enabled to prevent further database drift. 4. Restoration and verification: The clean snapshot is restored to an isolated staging area to verify database integrity and asset completeness before being pushed to production. 5. Post-recovery check: Once deployed, we re-run operational tests and hand the environment back to you for sign-off.
What you need to supply
To allow the Technology department to restore an environment without unnecessary delays, you must supply:
- The precise URL or subsystem showing corruption or data loss.
- The approximate timestamp when the issue was first observed.
- A summary of recent actions taken prior to the failure (such as content updates, plugin additions, or credential changes).
- Root or administrator access credentials, if the failure has occurred on your self-hosted infrastructure.
Failure states and technical boundaries
Backups cannot resolve every operational eventuality. You should be aware of the following technical constraints:
- Third-party host outages: If your project sits on an external host that experiences hardware corruption without their own server-side backups, our recovery is limited to the latest local repository and database snapshot stored on our internal systems. Any real-time data created between that snapshot and the outage will be unrecoverable.
- Concurrent database transactions: In high-traffic environments, rolling back to an earlier database snapshot will permanently overwrite transactions, user submissions, or orders that took place after the snapshot timestamp. In such cases, surgical data recovery may be required instead of a blunt snapshot rollback.
- Client-managed credentials: If access credentials to external storage buckets or hosting dashboards are lost or withheld, our team cannot retrieve or apply snapshot data.
Backup and recovery checklist
Before requesting an emergency rollback, confirm the following steps:
- [ ] Check whether the issue is isolated to browser caching or local network issues.
- [ ] Confirm whether any team member was editing content or configurations at the time of failure.
- [ ] Note down any visible error codes or server notices.
- [ ] Prepare all relevant details and submit an inquiry through the Ask Xylo chat.