Can I also create a backup of my web space myself?
You have the option, in the hosting.fr client interface, to set an individual restore point for a web space, in addition to automated backups. This can be useful, for example, if you want to experiment with a new CMS or plugins. We show you how to create an individual backup below.
A backup always includes the entire web space and cannot be applied to individual domains within the web space. If you manage multiple domains in a web space, keep in mind that restoring a backup will reset the data of all domains in this web space.
Attention: If you use a CMS such as Joomla or Wordpress, a backup of your databases is always necessary in such cases. A simple web space restoration is not enough to return to the original state.
To learn how to manage your database backups, please refer to the corresponding Helpdesk articles.
- Select “Products” in the menu on the left.
- In the “Products” menu, select “Web Hosting”.
- Under the web space, select “Show details”.
- Go to the “Backups” section and click on “Create a backup”.
- In the “Backups (manually)” section, click on “Overwrite backup” to set a manual restore point. The last manual backup will be overwritten. The backups automatically created by the system will remain intact.
Even if you have not yet created a manual backup, please choose “Overwrite backup” at this stage.
- Give a name to the restore point and confirm the creation of the backup by clicking the Save button.
Manual vs automatic backups: when to use which
A manual webspace backup is best understood as a deliberate restore point you create before a known change. It is most useful when you are about to perform an action that could break the site, such as updating a CMS, installing a plugin, changing templates, or modifying code. The value is timing: you control exactly when the snapshot is created, so you can roll back to a known-good state that matches “right before the change.”
Automatic backups serve a different purpose. They are designed for general safety and recovery from unexpected events, but they may not align precisely with your planned change window. Depending on retention and schedule, the most recent automatic backup might be older than the moment you need, or it may not exist for the exact time you made a breaking change.
Use this practical rule:
- Use manual backups before planned updates, migrations, or experiments.
- Rely on automatic backups as baseline protection for incidents you did not anticipate.
Treat them as complementary. Manual backups reduce risk around planned work; automatic backups provide safety net coverage.
What’s included in a webspace backup
Before you rely on a webspace backup as your rollback strategy, confirm what it actually captures. In many hosting environments, “webspace” primarily means website files stored in the web directory. That typically covers your application code, media uploads, and configuration files that live inside the file system.
However, websites often depend on components outside the file system:
- Databases (for CMS content, user accounts, orders, settings)
- Email data (mailboxes are usually separate from webspace)
- External services (CDN configuration, DNS, third-party integrations)
The essential operational implication is that restoring only files may not fully restore the website to a consistent working state if the database has changed. For example, a CMS plugin update can change database tables. In that situation, a rollback often requires both a file restore and a database restore taken from the same point in time.
Use webspace backups as a file-level restore point, and ensure you have an aligned database backup strategy whenever your planned change can affect database structure or content.
Pre-backup checklist: how to create a reliable restore point
A backup is most valuable when it represents a stable, consistent state. If you create a backup while files are actively changing or while an update is mid-process, the restore point may not behave as expected.
Before creating a manual backup, follow this checklist:
- Confirm the website is currently working as expected (so you’re backing up a known-good state).
- If you are about to run an update, ensure the site is not already in a partial update state.
- Avoid running backups during heavy write activity (large imports, batch image processing, or high-traffic periods) when possible.
- If your application supports it, consider enabling a short maintenance window for high-impact changes so files and data aren’t changing during the snapshot.
- If the change may affect the database, create a database backup at the same time so you can restore a consistent pair (files + database).
This checklist does not add complexity; it increases the chance that the restore point will actually be useful when you need it.
Naming and retention best practices for restore points
Manual backups are only helpful when you can identify the correct restore point quickly and you retain it long enough to be usable. The most common failure mode is a list of backups with unclear names, where the correct one is hard to find during an incident.
Recommended naming format:
- Include date/time and a short reason.
- Example: 2025-12-16_before_wordpress_update or 2025-12-16_before_theme_change.
Retention guidance:
- Keep backups created before significant changes until you have confirmed the system is stable (for example, for several days after the update).
- Remove old manual backups that no longer serve a purpose, mainly if storage or retention limits apply.
- Create backups consistently around change events so your backup list reflects meaningful milestones rather than random snapshots.
This discipline turns manual backups into a reliable rollback system rather than an unstructured archive.