AlexHost Backup Policy: Complete Technical Guide to Data Protection and Recovery

Understanding exactly how your hosting provider handles backups is not optional — it is a foundational requirement for any serious infrastructure decision. AlexHost maintains a structured, tiered backup policy that varies by service type, with clearly defined responsibilities for both the provider and the client. This guide covers every aspect of that policy: backup frequency, restoration procedures, cost implications, and the critical gaps you must fill with your own backup strategy.

What Is AlexHost's Backup Policy?

AlexHost's backup policy is a tiered data protection framework in which the frequency and scope of automated backups depend on the hosting service type. Shared and LiteSpeed hosting plans receive daily automated backups, VPS environments are backed up weekly, and dedicated servers receive no provider-managed backups whatsoever. Restoration is available on request through the support team, subject to the conditions described below.

This policy exists to provide a baseline safety net, not a comprehensive disaster recovery solution. The distinction matters enormously in practice: a provider-managed backup is a best-effort snapshot taken at a point in time, and its integrity is contingent on the state of your files at the moment the snapshot runs. AlexHost explicitly does not guarantee restoration from every backup, which makes client-side backup management an operational necessity rather than an optional precaution.

Backup Coverage by Service Type

Each hosting tier at AlexHost operates under a different backup model. The table below summarizes the key parameters across all service categories.

Shared and LiteSpeed Hosting Backups

For clients on Shared Web Hosting plans, daily backups are performed automatically by AlexHost infrastructure. These backups capture an exact copy of the account's file system and associated databases at the time the snapshot is taken. If a restoration is needed — due to accidental file deletion, a corrupted database, or a botched deployment — the support team can retrieve and restore from the most recent available backup.

A critical technical nuance here: daily backups do not mean point-in-time recovery. If your database is corrupted at 11:00 PM and the backup runs at midnight, the corrupted state is what gets captured. The previous day's snapshot is the last clean recovery point. This 24-hour window of potential data loss is a known limitation of daily backup cycles and should factor into how you manage deployments and database modifications.

VPS Backup Policy

VPS environments present a fundamentally different risk profile. Clients running VPS Hosting have root-level access, which means they can install software, modify system files, reconfigure services, and make changes that extend far beyond a typical shared hosting account. A weekly backup cycle reflects the increased complexity of snapshotting a full virtual machine environment, but it also means up to seven days of changes could be unrecoverable in a worst-case failure scenario.

For VPS clients, this creates a clear operational requirement: you must implement supplementary backup mechanisms at the application or filesystem level. Common approaches include:

• Automated database dumps using mysqldump or pg_dump scheduled via cron, with output written to a remote storage location
• Incremental file synchronization using rsync over SSH to an offsite destination
• Snapshot-based backups using tools like Timeshift, Bacula, or Duplicati configured to run daily or more frequently
• Application-level backups for platforms like WordPress (UpdraftPlus, BackWPup) or custom applications with built-in export functionality

If you are managing a control panel environment, VPS Control Panels such as cPanel, Plesk, or DirectAdmin all include native backup scheduling tools that can be configured independently of the provider's snapshot cycle.

Dedicated Server Backup Policy

Dedicated servers receive no provider-managed backups. This is standard practice across the industry for bare-metal infrastructure: the client has full hardware-level control, and the operational complexity of snapshotting diverse, client-configured environments makes provider-side automation impractical.

Clients running Dedicated Servers are entirely responsible for designing, implementing, and testing their own backup and disaster recovery architecture. This typically involves:

• Off-server storage targets — a separate storage server, NAS device, or cloud object storage (S3-compatible endpoints, Backblaze B2, Wasabi)
• Backup software — Veeam, Amanda, Bacula, BorgBackup, or Restic depending on the OS and workload
• Backup verification — automated restore tests run on a schedule to confirm backup integrity, not just existence
• Retention policies — a grandfather-father-son (GFS) rotation scheme is the industry standard, maintaining daily, weekly, and monthly restore points

Failing to implement an independent backup strategy on a dedicated server is one of the most common and most costly mistakes in self-managed infrastructure.

Backup Integrity and Provider Liability

AlexHost's policy includes an explicit and important disclaimer: the provider is not responsible for the state of client files at the time of backup, nor for the state of the backup itself. This is not unusual legal language — it reflects a genuine technical reality.

Backups are snapshots of whatever exists at a given moment. If your files are already corrupted, infected with malware, or partially deleted when the snapshot runs, the backup captures that degraded state. A backup of a compromised WordPress installation is a compressed archive of a compromised WordPress installation. This is why security hygiene — keeping software updated, using strong credentials, deploying SSL Certificates to prevent man-in-the-middle attacks on your admin interfaces — is inseparable from a sound backup strategy.

Additionally, backups are not performed for stopped or suspended services. If a service is inactive, no new snapshots are generated. This has a practical implication: if you suspend a service temporarily and then need to restore data, you are limited to whatever backup existed at the time the service was last active.

Backup Restoration Costs and Conditions

Under normal operating conditions, backup restoration is provided at no additional charge during the active service period. However, two specific scenarios introduce cost and eligibility constraints.

Post-termination restoration: If a service has been terminated or deleted due to non-payment, and the client subsequently requests restoration of the last available backup, AlexHost may charge a fee of 20 EUR to cover the technical effort involved in locating and restoring the data. This fee applies only when the restoration is paired with the reactivation of a service — it is not a standalone data retrieval service.

Acceptable Use Policy violations: If a service was terminated due to a violation of AlexHost's Acceptable Use Policy (AUP), restoration from backup is not available under any circumstances. This is a hard policy boundary, not a negotiable condition.

The practical takeaway: treat your backup access window as coterminous with your active service subscription. Allowing a service to lapse into non-payment is not just a billing issue — it is a data access risk.

Why Provider Backups Are Not a Substitute for Your Own

This point deserves direct treatment because it is frequently misunderstood. Provider-managed backups serve a specific and limited purpose: they protect against infrastructure-level failures and provide a recovery option for accidental data loss within the backup retention window. They do not protect against:

• Ransomware or malware that encrypts or destroys files before the next backup runs
• Logical corruption introduced gradually over multiple backup cycles, where all retained snapshots contain the corrupted state
• Compliance requirements that mandate specific retention periods, geographic storage locations, or encryption standards
• Application-specific recovery needs, such as restoring a single database table without overwriting the entire account
• Zero-downtime recovery, where a full provider-side restoration may take hours while your own local backup can be deployed in minutes

For businesses running production workloads — e-commerce stores, SaaS applications, client-facing portals — the 3-2-1 backup rule remains the baseline standard: three copies of data, on two different media types, with one copy stored offsite.

Email and Domain Data Considerations

Clients using Email Hosting should verify separately what backup provisions apply to mailbox data, as email stores have different recovery characteristics than web files. Similarly, domain registration data managed through Domain Registration is not subject to backup in the traditional sense — domain ownership records are maintained at the registry level — but ensuring your contact information and renewal settings are current is an equivalent form of data protection for your namespace.

Technical Decision Matrix: Backup Strategy by Hosting Type

Use this matrix to determine the minimum supplementary backup actions required based on your AlexHost service.

Key Takeaways: Operational Checklist

• Confirm which service tier you are on and verify the applicable backup frequency before assuming daily coverage exists
• Never rely exclusively on provider backups for production data — implement at least one independent, client-controlled backup mechanism
• Schedule and test restoration procedures periodically; an untested backup is an unverified backup
• Keep services in active, paid status to maintain access to backup restoration without incurring the 20 EUR recovery fee
• For VPS environments, configure application-level and filesystem-level backups to run more frequently than the weekly provider snapshot cycle
• For dedicated servers, design a full backup architecture before deploying any production workload
• Ensure your backup copies are stored in a geographically separate location from your primary hosting environment
• Verify that backups capture clean, malware-free data by maintaining strong security practices on your hosting environment at all times

Frequently Asked Questions

Does AlexHost perform backups automatically, or do I need to enable them?

Backups for shared and LiteSpeed hosting are performed automatically by AlexHost without any client configuration required. For VPS plans, weekly snapshots are also taken automatically. Dedicated server clients must configure and manage their own backup systems entirely.

How do I request a backup restoration from AlexHost support?

Submit a request through the AlexHost support system specifying the service, the approximate date of the data you need restored, and the specific files or databases affected. Restoration is performed by the technical team and is available at no charge during an active service period.

What happens to my backups if I cancel my hosting plan?

Once a service is terminated or deleted due to non-payment, backup access is not guaranteed. If you request restoration after termination, AlexHost may charge 20 EUR for the recovery effort, and this only applies when the service is being reactivated. If termination was due to an AUP violation, no restoration is possible.

Can I download my own backup copy from the AlexHost control panel?

For shared hosting accounts managed through cPanel, you can generate and download a full account backup directly from the cPanel Backup Wizard at any time. VPS clients with root access can create their own snapshots or file archives using standard Linux utilities. This is the recommended approach for maintaining client-controlled recovery points.

Is the weekly VPS backup a full snapshot or an incremental backup?

AlexHost performs snapshot-based backups for VPS environments. The technical implementation means the snapshot captures the state of the virtual disk at the time of execution. Clients requiring more granular recovery points — such as daily or hourly snapshots — must implement those independently using tools available within their VPS environment or by configuring a VPS with cPanel that includes built-in backup scheduling capabilities.