Briefly explained:<\/strong> A backup is an additional copy of your data from a specific point in time. It allows data to be restored from a previous backup state. A backup does not prevent an error or an attack \u2013 but it can be crucial if data is needed again after such an event.<\/p>\n<\/blockquote>\n\n\n\n A backup is a separate copy of data that existed at a specific point in time.<\/p>\n\n\n\n Simplified:<\/p>\n\n\n\n If a file is deleted or modified later, an older version may be able to be recovered from an existing backup.<\/p>\n\n\n\n The decisive factor here is the time of the backup. A backup fundamentally contains the state of the backed-up data at the respective time of the backup.<\/p>\n\n\n\n Websites and hosting accounts are constantly changing. Files are edited, emails received, databases updated, WordPress plugins installed, and content published.<\/p>\n\n\n\n Errors may occur during this process.<\/p>\n\n\n\n Typical situations include, for example:<\/p>\n\n\n\n An existing backup state can offer a possibility in such situations to restore required data from a previous state.<\/p>\n\n\n\n The term \u201ewebsite\u201c is often used as if it were a single file. In fact, modern websites usually consist of multiple components.<\/p>\n\n\n\n For a WordPress website, this includes, for example:<\/p>\n\n\n\n The files and the database fulfill different tasks.<\/p>\n\n\n\n For example, the files include WordPress itself, plugins, themes, and uploaded media. The database stores posts, pages, settings, and much other dynamic information, among other things.<\/p>\n\n\n\n Important:<\/strong> Backing up only the WordPress files is therefore not automatically a complete backup of the website. For database-driven websites, the database is also part of the relevant data set.<\/p>\n<\/blockquote>\n\n\n\n A complete hosting account usually includes more than just the actual website.<\/p>\n\n\n\n Depending on the account and the services used, the following data, among others, may be present:<\/p>\n\n\n\n Therefore, during a restoration, it is important to distinguish, which data is actually required<\/strong>.<\/p>\n\n\n\n If only a single file is missing, it would be unnecessary to automatically roll back the entire hosting account to an older state for that reason.<\/p>\n\n\n\n The same applies, for example, to email data.<\/p>\n\n\n\n Depending on the situation, a recovery can be carried out in a targeted manner:<\/p>\n\n\n\n At CURIAWEB, recoveries can therefore be carried out in a targeted manner depending on the specific problem.<\/p>\n\n\n\n A backup state \u2013 often also called a recovery point or restore point \u2013 refers to a saved state from a specific point in time.<\/p>\n\n\n\n A simplified example:<\/p>\n\n\n\n If, for example, you notice on August 30th that a file was accidentally modified as early as August 28th, a backup from August 29th might also already be affected.<\/p>\n\n\n\n For a successful restoration, a backup state must therefore be selected in which the required data was still present in the desired state.<\/p>\n\n\n\n This point is particularly important.<\/p>\n\n\n\n Assuming a faulty change was made on Monday, but only discovered on Thursday.<\/p>\n\n\n\n The backups from Tuesday, Wednesday, and Thursday may already contain the faulty change.<\/p>\n\n\n\n In this case, a backup from before Monday may need to be used.<\/p>\n\n\n\n Practical Tip:<\/strong> If you need a recovery, try to determine as precisely as possible when the data was still correct. This helps in selecting the appropriate backup version.<\/p>\n<\/blockquote>\n\n\n\n CURIAWEB creates daily backups of the hosting data. The backup versions are kept on a rolling basis for 30 days.<\/p>\n\n\n\n Simplified, this means:<\/p>\n\n\n\n This makes restore points from different days available, as long as they are within the retention period and the respective backup was created successfully.<\/p>\n\n\n\n The fuses are with JetBackup 5<\/strong> managed.<\/p>\n\n\n\n A backup should not be exclusively dependent on the same production system whose data it is intended to protect.<\/p>\n\n\n\n CURIAWEB therefore stores the backups on separate backup servers in a separate data center.<\/p>\n\n\n\n Simplified:<\/p>\n\n\n\n As a result, the backups are structurally separated from the productive hosting system.<\/p>\n\n\n\n If the only backup were located exclusively on the same server as the production data, a serious problem could affect both datasets simultaneously.<\/p>\n\n\n\n Separate storage reduces this shared dependency.<\/p>\n\n\n\n However, that does not mean that a backup rules out every conceivable risk. Backups are an important component of a protection and recovery concept, but they are not a guarantee that data can never be lost.<\/p>\n\n\n\n CURIAWEB backups are retained on a rolling basis for 30 days.<\/p>\n\n\n\n As a result, older backup versions are removed from the backup rotation over time.<\/p>\n\n\n\n If, for example, you only notice several months later that a specific file is needed, the corresponding historical backup state may no longer be available.<\/p>\n\n\n\n A regular backup with limited retention time is therefore not the same as a long-term archive.<\/p>\n\n\n\n A backup serves primarily to be able to restore data from a previous backup state after errors, losses, or other problems.<\/p>\n\n\n\n In contrast, an archive typically pursues the goal of specifically retaining certain data over a longer period of time.<\/p>\n\n\n\n Simplified:<\/p>\n\n\n\n If certain files or data need to be retained for months or years, rolling backup retention should not be relied upon exclusively for this purpose.<\/p>\n\n\n\n Yes. The existing backup statuses can be accessed via JetBackup 5<\/strong> be viewed.<\/p>\n\n\n\n This allows you to check, for example, which backup times are available for your hosting account.<\/p>\n\n\n\n However, the actual recovery is performed by CURIAWEB.<\/p>\n\n\n\n The customer recovery function is deliberately disabled in CURIAWEB.<\/p>\n\n\n\n A restore can \u2013 especially in the case of extensive hosting accounts \u2013 consume considerable server resources. If several large restorations are carried out simultaneously or unnecessarily, this can result in a high server load.<\/p>\n\n\n\n Additionally, there is the risk of user error. An incorrectly selected full restore can replace current production data with an older state.<\/p>\n\n\n\n CURIAWEB therefore performs restores in a controlled manner. This makes it possible to check prior to the restore which backup status and data volume are actually required.<\/p>\n\n\n\n Important:<\/strong> The restriction only applies to independent restoration. You can view the existing backup states in JetBackup 5 and then inform CURIAWEB which data from which state is needed.<\/p>\n<\/blockquote>\n\n\n\n Imagine that you accidentally deleted a single file today.<\/p>\n\n\n\n A complete account restore to yesterday's state could simultaneously reset other data that has changed correctly since then.<\/p>\n\n\n\n This can concern current website content or email data, for example.<\/p>\n\n\n\n Therefore, if technically feasible and appropriate for the specific case, a targeted recovery of the actually required data is preferable.<\/p>\n\n\n\n During a full recovery, a larger dataset is restored to the state of the selected backup point in time.<\/p>\n\n\n\n This also means that changes made after this backup point in time may be affected.<\/p>\n\n\n\n Example:<\/p>\n\n\n\n Before a complete restore, it must therefore be precisely clarified what impact the recovery could have on current data.<\/p>\n\n\n\n On a static website, little may change between two days.<\/p>\n\n\n\n In contrast, dynamic systems can continuously generate new data.<\/p>\n\n\n\n Examples are:<\/p>\n\n\n\n A complete restore to an older state can therefore have a significantly greater impact than the recovery of a single file.<\/p>\n\n\n\n Backups are no substitute for security measures.<\/p>\n\n\n\n For example, a backup does not prevent:<\/p>\n\n\n\n However, the backup can play an important role in recovery after such an event.<\/p>\n\n\n\n This point is also frequently overlooked.<\/p>\n\n\n\n For example, if a website has already been compromised for several days, newer backups may also contain the compromised state.<\/p>\n\n\n\n Therefore, it is not always enough to simply restore the newest backup.<\/p>\n\n\n\n In the event of a security incident, it must first be determined as precisely as possible when the problem arose and whether the selected backup state might already be affected.<\/p>\n\n\n\n If a website has gone down or been damaged due to a specific cause, a restore does not necessarily fix that cause.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n Therefore, depending on the cause, the actual problem must also be resolved after a recovery.<\/p>\n\n\n\n Before extensive work on a website, it is advisable to consider recovery options.<\/p>\n\n\n\n This applies, for example, before:<\/p>\n\n\n\n In particular, it should be checked whether a suitable, up-to-date backup exists and which data could continue to change during the work.<\/p>\n\n\n\n When contacting CURIAWEB for a restoration, the more precise the information provided, the more helpful it will be.<\/p>\n\n\n\n Of particular importance are:<\/p>\n\n\n\n For a single file, you should also provide the file name and path if possible.<\/p>\n\n\n\n For email data, the affected email account should be specified.<\/p>\n\n\n\n If you need data from an existing backup, contact CURIAWEB Support. Please let us know as precisely as possible which backup version and which data you need.<\/p>\n\n\n\nWhat is a backup?<\/h2>\n\n\n\n
Production data\n \u2193\n Backup\n \u2193\nBackup status<\/code><\/pre>\n\n\n\nWhy are backups important?<\/h2>\n\n\n\n
\n
What components does a website consist of?<\/h2>\n\n\n\n
WordPress files\nThemes\nPlugins\nUploads and images\nConfiguration files\nMySQL database<\/code><\/pre>\n\n\n\n\n
What can a hosting backup include?<\/h2>\n\n\n\n
\n
It doesn't always have to be the complete account that is restored<\/h2>\n\n\n\n
![\"Backed-up](\"https:\/\/www.curiaweb.ch\/wp-content\/uploads\/2026\/08\/Detailansicht-eines-Backup-Stands-1024x603.jpg\")
<\/figure>\n\n\n\nsingle file\n\nspecific email data\n\nspecific dataset\n\nor\n\ncomplete hosting account<\/code><\/pre>\n\n\n\nWhat does a backup status mean?<\/h2>\n\n\n\n
![\"Daily](\"https:\/\/www.curiaweb.ch\/wp-content\/uploads\/2026\/08\/backup-uebersicht-curiaweb-1024x394.jpg\")
<\/figure>\n\n\n\nAugust 30 \u2192 current backup status\nAugust 29 \u2192 previous backup status\nAugust 28 \u2192 older backup status\nAugust 27 \u2192 older backup status\n...<\/code><\/pre>\n\n\n\nThe newest backup is not automatically the right backup<\/h2>\n\n\n\n
\n
How do backups work at CURIAWEB?<\/h2>\n\n\n\n
![\"View](\"https:\/\/www.curiaweb.ch\/wp-content\/uploads\/2026\/08\/etBackup-5-Uebersicht-in-cPanel-1024x391.jpg\")
<\/figure>\n\n\n\ndaily backup\n \u2193\n30 days retention\n \u2193\noldest backup is removed\n \u2193\nnew backup is added<\/code><\/pre>\n\n\n\nWhy are the backups stored separately?<\/h2>\n\n\n\n
Productive hosting server\n \u2193\n Backup transmission\n \u2193\nSeparate backup infrastructure\n \u2193\n Separate data center<\/code><\/pre>\n\n\n\nWhy does a separate backup infrastructure make sense?<\/h2>\n\n\n\n
30 days of retention does not mean unlimited archiving<\/h2>\n\n\n\n
Backup and archive fulfill different tasks<\/h2>\n\n\n\n
Backup\n\u2192 recovery after a problem\n\nArchive\n\u2192 long-term retention of specific data<\/code><\/pre>\n\n\n\nCan I see my backups on CURIAWEB?<\/h2>\n\n\n\n
Why can backups not be restored independently?<\/h2>\n\n\n\n
\n
Why a targeted restore is often better<\/h2>\n\n\n\n
What happens during a full restore?<\/h2>\n\n\n\n
Backup:\nMonday 02:00 AM\n\nRestore:\nWednesday\n\nChanges made after Monday 02:00 AM\ncannot be included in the restored\ndatabase.<\/code><\/pre>\n\n\n\nParticularly important for dynamic websites<\/h2>\n\n\n\n
\n
A backup does not prevent an attack<\/h2>\n\n\n\n
a password is stolen\n\na security vulnerability is exploited\n\nmalicious code is introduced\n\na file is deleted\n\na plugin causes an error<\/code><\/pre>\n\n\n\nA backup may already contain an error<\/h2>\n\n\n\n
Restoration and troubleshooting are not the same<\/h2>\n\n\n\n
insecure plugin\n \u2193\nwebsite compromised\n \u2193\nrestore older backup\n \u2193\ninsecure plugin still present\n \u2193\nre-compromise possible<\/code><\/pre>\n\n\n\nBackups before major changes<\/h2>\n\n\n\n
major WordPress updates\ntheme changes\nextensive plugin modifications\ndatabase work\nwebsite migrations\nmajor structural changes<\/code><\/pre>\n\n\n\nWhat should you specify as precisely as possible during a restore?<\/h2>\n\n\n\n
\n
Have a backup restored<\/h2>\n\n\n\n