Hostinger Backup Guide: Download, Restore & Daily Backups

Quick answer: does Hostinger include backups?

Hostinger’s current support guidance describes weekly backups for web and cloud hosting and daily backups for Business or higher plans. The names and features shown in your subscription can differ from public offers, so check the actual backup panel for available dates and controls. A downloadable WordPress backup should include the files and the database you need to rebuild the site.

For an important website, keep a separate copy under your own control and test recovery. Automatic backups are useful, but a recovery plan also needs a known restore point, access to the account and a way to preserve valuable changes made after that point.

This guide covers hosted WordPress recovery. Hostinger’s download documentation says its backup-download feature is unavailable for Hostinger AI Builder websites. Do not assume a WordPress procedure applies to every Hostinger product.

What a WordPress backup must contain

WordPress uses files and a database. Files include uploaded images, themes, plugins and configuration. The database stores content and many settings. Keeping only one half can leave you with incomplete recovery: posts may remain while images disappear, or software files may exist without the content that makes the website useful.

Make a short inventory before you download anything. Identify the domain, the installation directory and the correct database. If the account hosts several sites, a similarly named archive can be easy to confuse with the one you need. Label each saved copy with the site and recovery date.

Also document services that live outside WordPress. DNS, business email, analytics, payment accounts and third-party licenses can require separate recovery steps. A website archive is not proof that all those services have been captured.

A reliable backup should be understandable to someone other than its creator. Keep a small recovery note that explains what the files contain, which database belongs to them and where the current access instructions are stored securely. This helps when the usual site manager is unavailable.

Weekly vs daily backups: choose by the work you could lose

Backup frequency should match how often valuable information changes. A simple portfolio updated occasionally has a different recovery requirement from a store receiving orders every hour. Consider the amount of work you would have to recreate if you returned to the latest available copy.

A daily copy does not capture every change made throughout the day. If losing several hours of transactions would create a serious problem, evaluate a process with a shorter interval and a way to reconcile external transaction records.

Frequency and retention are separate decisions. Frequent backups help with recent mistakes; a longer history helps when a problem is discovered later. Inspect the dates actually available in your account rather than relying on a plan label alone.

How to download your Hostinger backup

Open the website’s dashboard in hPanel and locate Backups. In the Restore and download area, select the file backup date you need, request its preparation and download the archive when it is ready. For the database, select the correct database and recovery date, prepare the download and save the result.

The official download guide identifies file archives as .tar.gz and database downloads as .sql.gz. Leave the original downloaded copies intact while you work with a duplicate. Matching file and database dates reduces the chance of mixing components from different versions of the site.

Preparation can take time. Check that the download completed rather than treating a small partial file as a successful backup. Make sure you have adequate local storage and keep the copy somewhere you can find when the website is unavailable.

After downloading, label the recovery set clearly. Record the date shown in the panel, the site’s identity and the components included. You should be able to distinguish a planned pre-update backup from an older automated copy without opening every archive.

Do not place a sensitive backup in a public website directory or share a public download link casually. Database exports can contain account information and private submissions. Protect the stored copy and limit access to the people responsible for recovery.

Before restoring: preserve the current state

A restore replaces existing website data with an earlier version. Before confirming it, decide which current information needs to be preserved. New orders, user registrations, articles and form submissions may not exist in the selected backup.

Save the current state if you can do so safely, even when it is broken. It can contain valuable recent data and evidence about what caused the failure. A working older copy and a current damaged copy serve different purposes during recovery.

Write down why you are restoring. Was the problem caused by a plugin update, a design change, deleted files or a suspected intrusion? The cause helps you choose a useful recovery point. Selecting the newest backup without checking whether it already contains the problem can waste time.

Tell the people who maintain the site when the restore will happen. Pause conflicting edits and plan how to handle new activity during the recovery window. For a business website, agree on who will confirm that forms, orders and account access work afterward.

How to restore a WordPress website in hPanel

Hostinger’s WordPress restoration guide describes opening Websites, choosing the website dashboard and locating Backups. Under Restore and Download, choose a date in Website backup and select Restore website. Read the overwrite warning before confirming.

The combined WordPress option restores the site’s files and database together. The same guide says that if Website backup is unavailable, the components must be restored separately. Follow the controls and instructions for your actual account rather than assuming every site exposes the same screen.

Monitor the restore history and wait for completion before testing. Starting another restore because the public page still looks old can complicate the process. A cache may also show content from before the recovery, so distinguish the stored website from a cached response.

For a separate file-and-database recovery, confirm that the components belong together. If you are unsure which database the site uses, stop and identify it before overwriting anything. Restoring an unrelated database is not a useful troubleshooting experiment.

Keep a record of the chosen date and the outcome. If the recovered website is still broken, that record helps you assess whether the restore point was unsuitable or whether the cause lies outside the backed-up installation.

After the restore: test the website as a visitor

Start with the public homepage, then open a representative article, a landing page and the most important conversion page. Check images, navigation and internal links. A homepage that loads does not prove that the whole website recovered correctly.

Test administrative access and inspect whether the intended plugins and theme are active. Avoid updating everything immediately. Confirm the baseline first, then reintroduce necessary changes in a controlled sequence so you can identify a new failure if one appears.

For forms, submit an appropriate test and confirm receipt. For a store, use a suitable test method to check the purchase flow and compare website records with external payment information. A technically successful restore can still leave business records needing reconciliation.

Clear relevant website and delivery caches when appropriate, then recheck a fresh visitor view. Inspect HTTPS and redirects if access behaves differently across the main domain and www address. Do not change DNS simply because a cached page looks outdated.

Check scheduled tasks and connected services that may send messages or process data. You want to avoid duplicate actions after returning to an older state. Finally, document the result and take a fresh known-good backup once the site is stable.

When is the daily-backup add-on worth considering?

Hostinger’s daily-backup guidance describes an add-on purchase for Web Single and Premium through Backups and Add Daily Backups. Check the current account quote and the benefits already included in your subscription before buying an extra service.

Compare the add-on with an upgrade that includes the recovery features you need. Include the renewal cost of both options. A lower first payment does not necessarily make one approach cheaper over the period you expect to keep the website.

The right choice depends on workload. If you already have enough website capacity and storage, a backup option may address the specific need. If you also need broader capacity, compare the full plan rather than evaluating each extra in isolation.

Our Hostinger Premium vs Unlimited guide examines those broader tradeoffs. Plan names change, and older subscriptions can differ, so use the features shown for your own account.

Keep an independent copy and a recovery note

Store an important recovery set outside the same hosting account. This provides another route when account access is unavailable or the copy you need is no longer listed in the panel. Decide who owns that copy and how they can retrieve it securely.

Keep more than one useful version where your storage and privacy requirements allow it. Label successful recovery points and retain a clean pre-change copy for significant work. Avoid leaving an unorganized pile of archives with no explanation of which version is usable.

Test with a separate environment when practical. Confirm that the archive opens, the database is usable and the website can be reconstructed. Prevent a test installation from sending real customer emails or processing real payments during the rehearsal.

Your recovery note should include the installation identity, required components, the restore date and a list of critical checks. Store credentials securely rather than embedding passwords in a plain-text note attached to the backup.

Review the plan when the website changes. Adding a store, memberships or more frequent publishing can make an old backup interval inadequate. Recovery requirements should evolve with the information the site creates.

Common mistakes that make backups less useful

The first mistake is assuming that a scheduled backup always completed. Inspect recent dates periodically and investigate missing copies. A maintenance routine that checks recovery evidence is stronger than one that simply trusts a feature label.

The second is mixing unrelated dates or installations. File and database consistency matters, especially after software updates or media changes. Labeling the set clearly is a small task that prevents a large amount of uncertainty later.

The third is treating a restore as a full security cleanup. A backup may already contain the cause of an intrusion. If compromise is suspected, identify the cause, restore a suitable clean point and address access or software weaknesses before returning to normal operation.

The fourth is forgetting external dependencies. Domain access, DNS, email and payment services need their own operational records. Check which services were affected and avoid promising that a WordPress restore will repair every connected system.

Frequently asked questions

Our verdict: choose recoverability, not just a feature label

Hostinger’s backup controls can make WordPress recovery more accessible, but reliable operation still needs preparation. Know what is backed up, preserve a consistent recovery set, keep an independent copy and test the important parts of the site after restoring.

Choose a backup interval that matches the changes your website creates. Compare backup and hosting costs alongside renewal terms. Our renewal-price guide and TECHSOLV10 coupon guide can help you evaluate the complete purchase.