---
title: "Backup strategy"
manual: "TYPO3 Explained"
version: "11.5"
permalink: "https://docs.typo3.org/permalink/t3coreapi:security-backups@11.5"
source: "Security/Backups/Index.rst"
rendered: "2026-10-21T15:30:00+00:00"
---

> [!WARNING]
> **Attention**
>
> TYPO3 v11 has reached end-of-life as of October 31th 2024 and
> is no longer being maintained. Use the version switcher on the top
> left of this page to select documentation for a supported version of TYPO3.
>
> Need more time before upgrading?
> You can purchase Extended Long Term Support (ELTS) for TYPO3 v11 here:
> [TYPO3 ELTS](https://typo3.com/services/extended-support-elts).

# Backup strategy {#security-backups}

Backups are usually in the responsibility of the system administrator.
Creating backups obviously does not improve the security of a TYPO3
site but they quickly become incredibly useful when you need to
restore a website after your site has been compromised or in the case
of a data loss.

## Components included in the backups {#security-backup-components}

To restore a TYPO3 project you need to have a backup of at least the
following data directories:

-   `fileadmin`
-   `typo3conf`

> [!NOTE]
> The directory structure is not *that* fixed: Especially with
> modern `Composer` based instances, a separation of the [project root](https://docs.typo3.org/permalink/t3coreapi:environment-project-path@11.5)
> and the [web server document root](https://docs.typo3.org/permalink/t3coreapi:environment-public-path@11.5) can be achieved.
> This is recommended from a security point of view since critical parts of
> the TYPO3 instance can be located outside of the web document root and are then not
> directly accessible from the outside. Important parts are the [var path](https://docs.typo3.org/permalink/t3coreapi:environment-var-path@11.5) and the [config path](https://docs.typo3.org/permalink/t3coreapi:environment-config-path@11.5)
> \- see [Environment API](https://docs.typo3.org/permalink/t3coreapi:environment@11.5) for details. The "config path" should
> be included in backups, while the "var path" could be left out since its content
> will be - with most instance configurations - recreated automatically if needed.

You do not need a backup of the `typo3temp/` directory, due to the
fact that all files are re-generated automatically if they do not
exist. Also a backup of the TYPO3 source code is not needed (unless
changes were made to the source code, which is not recommended). You
can always download the TYPO3 source packages from the TYPO3 website,
even for older versions of TYPO3.

In addition to the data directories listed above, a backup of the
database is required. For MySQL the command line tool `mysqldump` (or
`mysqldump.exe` for Microsoft Windows) is a good way to export the
content of the database to a file without any manual interaction (e.g.
as an automated, scheduled system task).

Once a backup has been created, it should be verified that it is
complete and can be restored successfully. A good test is to restore a
backup of a TYPO3 project to a different server and then check the
site for any errors or missing data. In a perfect world, these restore
checks should be tested frequently to ensure that the concept works
and continues working over a time period. The worst case would be that
you rely on your backup concept and when you need to restore a backup
you notice that the concept has not worked for months.

## Time plan and retention time {#security-backups-time-plan}

In most cases you should create a backup once a day, typically at a
time when the server load is low. Rather than overwriting the backup
from the previous day you should create a new backup and delete older
copies from time to time. Just having a backup from last night is not
sufficient for recovery since it would require that you notice the
need for a restore within 24 hours. Here is an example for a good
backup strategy:

-   keep one daily backup for each of the last 7 days
-   keep one weekly backup for each of the last 4 weeks
-   keep one monthly backup for each of the last 6 months
-   keep one yearly backup for each year

## Backup location {#security-backup-location}

Backups are typically created on the same server as the TYPO3 instance
and often stored there as well. In this case, the backup files should
be copied to external systems to prevent data loss from a hardware
failure. If backups are only stored on the local system and an
attacker gains full control over the server, he might delete or tamper with
the backup files. Protecting the external systems against any access from
the TYPO3 server is also highly recommended, so you should consider
"fetching" the backups from the TYPO3 system instead of "pushing" them
to the backup system.

When external systems are used they should be physically separated
from the production server in order to prevent data loss due to fire,
flooding, etc.

Please read the terms and conditions for your contract with the
hosting provider carefully. Typically the customer is responsible for
the backup, not the provider. Even if the provider offers a backup,
there may be no guarantee that the backup will be available. Therefore
it is good practice to transfer backups to external servers in regular
intervals.

In case you are also storing backups on the production server, make
sure that they are placed outside of the root directory of your
website and cannot be accessed with a browser. Otherwise everybody
could download your backups, including sensitive data, such as
passwords (not revealing the URL is not a sufficient measure from a
security perspective).

## Further considerations {#security-backups-further-considerations}

More sophisticated backup strategies, such as incremental backups and
distributed backups over several servers, geographically separated and
rotating backups, etc. are also achievable but out of scope of this
document.

Due to the fact that website backups contain sensitive information
(backend user details, passwords, sometimes customer details, etc.) it
is highly recommended to consider the secure encryption for these
files.