--- title: "How to Restore a Backup in ISPConfig" description: "Restore website files, a database or a mailbox from an ISPConfig backup, and understand exactly what each restore overwrites before you commit." url: "https://docs.noiz.ie/ispconfig/how-to-restore-a-backup-in-ispconfig/" section: "ISPConfig" categories: - "Control Panels > ISPConfig > Sites & Domains" - "Email > Migration & Backup" last_reviewed: "27 July 2026, against the ISPConfig release Noiz runs" --- # How to Restore a Backup in ISPConfig This guide covers putting a Noiz hosting account back to an earlier state from a backup ISPConfig has already taken: a website's files, a database, or a mailbox. It is written for Noiz clients who manage their own hosting through ISPConfig, and it deliberately spends more time on the decisions than on the clicking, because the clicking is the easy part. A restore is the one action in the panel that destroys current data on purpose, cannot be undone, and behaves differently depending on which of the three backup types you are restoring. **If you came here looking for how to restore part of a backup rather than all of it, you are in the right place, and there is nothing extra to do.** ISPConfig has no single account-wide archive to take apart. It stores website files, databases and mailboxes as separate backups with separate restore buttons, so a partial restore is the only kind ISPConfig performs. Restoring a database without touching the files, or one mailbox without touching the website, is the normal case rather than an advanced one. **Last reviewed:** 27 July 2026, against the ISPConfig release Noiz runs. This guide is written for Noiz hosting and is kept current against ISPConfig. It complements, and does not replace, the official ISPConfig documentation linked below. ### Official Documentation Reference - [The ISPConfig User Manual](https://www.ispconfig.org/documentation/user-manual/): the vendor's own reference for every form and field in the panel, including the **Backup** tab settings that decide what exists to restore in the first place. - [ISPConfig 3 Documentation](https://docs.ispconfig.org/): the official online documentation for the current interface. - [The backup and restore routine in the ISPConfig source, at release 3.3.1p1](https://git.ispconfig.org/ispconfig/ispconfig3/-/blob/3.3.1p1/server/lib/classes/backup.inc.php): the authoritative answer to what a restore actually does to your data. The behaviour described in this article was read from this file rather than assumed. - [ISPConfig release tags](https://git.ispconfig.org/ispconfig/ispconfig3/-/tags): the project's own list of releases, useful for checking whether guidance you find elsewhere was written for the version you are running. ## Prerequisites - You can [log in to the ISPConfig control panel](/ispconfig/how-to-log-in-to-the-ispconfig-control-panel/). - Backups already exist. A restore can only offer you what was captured earlier, so if backups were never switched on for the site or mailbox there is nothing in the list to restore. Setting that up is covered in [How to Back Up Websites, Databases and Mailboxes in ISPConfig](/ispconfig/how-to-back-up-your-websites-databases-and-mailboxes-in-ispconfig/). - An [FTP account](/ispconfig/how-to-create-an-ftp-account-in-ispconfig/) for the website, if you want to take your own copy of anything before you overwrite it. This is strongly recommended and the reason is explained below. - A clear answer to one question: *what exactly is wrong, and when did it start?* Restoring is not a diagnostic tool. If you do not know roughly when the problem began, you do not know which backup to pick, and a restore to the wrong date destroys good data as thoroughly as bad data. ## Read This Before You Click Restore ### A restore cannot be undone There is no undo, no staging copy, and no option to restore somewhere else so you can compare before committing. ISPConfig writes the backup straight over the live website, database or mailbox. The panel asks you to confirm once, and after that the current state of whatever you restored is gone. ### Take a fresh backup first, and mind the trap in doing so The safe habit is to capture the current state before replacing it, so that if the restore turns out to be the wrong call you can get back to where you started. On the website **Backup** tab, under the heading **Manual backup**, ISPConfig gives you two on-demand buttons for exactly this, **Make backup of databases** and **Make backup of web files**, so you do not have to wait for the overnight run. **The trap:** ISPConfig warns you about this when you click, and the warning is easy to skim past. Manual backups count towards the **Number of backup copies** limit set on the site. If that limit is already reached, taking a fresh backup deletes the oldest one to make room, and the oldest one may be precisely the backup you were about to restore. Look at the dates in the **Existing backups** list first. If the backup you want is the oldest row, do not take a manual backup: take your own copy over FTP instead, which does not touch the panel's retention at all. Mailboxes have no on-demand backup button and no download button, so there is no in-panel way to snapshot a mailbox before restoring it. To keep your own copy, connect a mail client over IMAP and drag the folders you care about into a local folder before you restore. This is worth doing, because a mailbox restore is the type most likely to surprise you. ### Backups hold content, not settings A restore brings back files, database contents and messages. It does not bring back anything you configured in the panel itself: PHP version, SSL certificates, redirects, cron jobs, DNS records, FTP accounts, mailbox settings and spam filter policies are all unaffected by a restore, in either direction. If your problem is a setting rather than content, restoring will not fix it and you will have overwritten good data for nothing. ## The Three Backup Types, and What Each Restore Really Does This is the section the official documentation does not give you, and it matters because the three types are not equally destructive. In the panel they all look like the same **Restore** button. ### Website files: a mirror, not a merge Restoring a website file backup puts the site's directory back to exactly the state captured in the archive. Changed files are reverted, deleted files are put back, and **files created since the backup are removed**. The panel's confirmation says only that restoring "will overwrite existing files in your website", which understates it: anything added after the backup date, including uploads, generated files and anything you installed since, is not merged in and does not survive. Two consequences worth planning around: - **Content added since the backup is lost.** On a site where visitors or customers upload files, that can mean losing real work even though the restore itself succeeded exactly as designed. - **Directories you excluded from backups are at risk.** Anything listed in **Excluded Directories** on the site's **Backup** tab was never captured, and the restore makes no exception for it. Because the archive does not contain those paths, mirroring the archive over the site removes their contents too, so an exclusion protects a directory from being backed up but not from being emptied. Copy those directories down over FTP before restoring. ### Databases: table by table, with leftovers A database restore replays the stored dump into the existing database. Every table present in the dump is dropped and recreated, so the data in those tables is fully replaced. Tables that exist in the live database but are *not* in the dump are left exactly where they are. The practical effect is that a database restore is not a clean slate. If a plugin, extension or update created new tables after the backup was taken, those tables survive the restore and sit alongside restored older data. That mismatch is a common cause of a site that is still broken after what looked like a successful restore. ### Mailboxes: additive A mailbox restore is the gentlest of the three. Messages from the backup are written back into the mailbox, and mail that arrived after the backup date is not removed. Depending on how the server stores mail for your account, restored messages either merge back into your existing folders or appear as a separate dated folder you can browse in your mail client. Two things to expect. First, duplicates: messages that were already there and are also in the backup can appear twice. Second, a resync. Your mail client will not show the change until it has talked to the server again, and on a large mailbox that can take a while. Mail already downloaded and removed from the server by a POP3 client is not affected by any of this. ## Restore a Website's Files 1. Log in to the ISPConfig control panel and open the **Sites** module. 2. Under **Websites**, click **Website**, then click the site you want to restore. 3. Open the **Backup** tab. Below the backup settings you will find **Existing backups**, a table of everything currently stored for this site. Read the table before you touch anything. The columns tell you what you are choosing between: - **Date**: when the backup was taken. Backups run overnight, so the newest scheduled row is usually from the early hours of the current day, not from a few minutes ago. - **Type**: **Website files** or **MySQL Database**. Both types share this one list, which is the single most common source of confusion on this screen. Check the type before you click **Restore**. - **Scheduler**: **Auto** for the scheduled run, **Manual** for one you triggered yourself. - **Backup format**, **Encrypted**, **Backup file** and **File size**: mostly informational. A file size far smaller than you expect is a warning sign worth investigating before you restore from it. 4. **Optional but recommended:** click **Download** on the row you intend to restore, and on the newest row as well. Within a few minutes each file appears in a folder named `backup` in your website's directory, alongside the public `web` folder rather than inside it, so it is not exposed to visitors. A website restore leaves that folder alone, so a copy downloaded beforehand is still on the server afterwards. Collect them over FTP, then delete them from the server, because they count against your disk quota while they sit there. Having the archive on your own machine is what turns an irreversible action into a recoverable one. 5. Click **Restore** on the row you want, with **Type** showing **Website files**. 6. Read the confirmation and accept it. ISPConfig replies that the restore has started and will take several minutes. The restore is queued rather than instant. ISPConfig hands it to the server and works through it in the background, which is why the panel says minutes rather than seconds. The site stays live throughout, and visitors during the restore may see a half-replaced site. If that matters, put up a holding page first. ## Restore a Database Database backups live in the same **Existing backups** list on the website's **Backup** tab, not under **Databases** in the left menu. If you went looking under **Databases** and found no backups, that is why. ISPConfig groups a site's databases with the site they belong to. 1. Open the website's **Backup** tab as above. 2. In **Existing backups**, find a row whose **Type** is **MySQL Database** and whose **Backup file** names the database you mean. A site with more than one database has one row per database per backup run, so match the name, not just the date. 3. Click **Restore** and confirm. Before you do, decide whether you also need the files from the same date. A database and the code that reads it are a matched pair, and restoring one without the other is a frequent cause of a site that gets worse rather than better. As a rule of thumb: restore the database alone when the data is wrong but the site works; restore both, from the same date, when the site broke after an update or an installation. Restoring a database does not change the database user or its password, and it does not touch your application's configuration file, since that lives in the files backup. If your site cannot connect after a restore, the cause is almost always a mismatch between a restored configuration file and the current credentials rather than a failed restore. [How to Create a Database and Database User in ISPConfig](/ispconfig/how-to-create-a-database-and-database-user-in-ispconfig/) sets out the four values an application needs, and [How to Set Database User Privileges in ISPConfig](/ispconfig/how-to-set-database-user-privileges-in-ispconfig/) covers what that user is allowed to do. ## Restore a Mailbox Mailbox backups are managed per mailbox, in the **Email** module, and are entirely separate from anything on the website side. A mailbox is backed up and restored on its own even when the domain it belongs to is also being backed up. 1. Open the **Email** module and, under **Email Accounts**, click **Email Mailbox**. 2. Click the mailbox you want to restore. 3. Open its **Backup** tab. Below the backup interval and copy count you will find that mailbox's own **Existing backups** list, showing **Date**, **Backup file** and **Filesize**. 4. Click **Restore** on the row you want and confirm. As with a website, the job is queued and takes several minutes. Two differences from the website side are worth knowing in advance, because they change how you prepare. There is no on-demand backup button for a mailbox, so you cannot snapshot it in the panel before restoring. There is also no download button, so a mailbox backup can only be restored in place. If you need your own copy of the current mail, take it over IMAP with a mail client before you restore. [How to Access Your Webmail in ISPConfig](/ispconfig/how-to-access-your-webmail-in-ispconfig/) covers reaching the mailbox, and [How to Create an Email Mailbox in ISPConfig](/ispconfig/how-to-create-an-email-mailbox-in-ispconfig/) covers the settings a client needs. ## How to Tell It Worked The panel's message means the job was accepted, not that it has finished. Confirm the result yourself: - **Website files**: load the site in a private browser window so you are not looking at a cached copy. Then check a file you know changed after the backup date and confirm it is back to its earlier state. Over FTP, check the modification dates in the site's `web` folder. - **Database**: open the database in phpMyAdmin from the **Databases** list and spot-check a record you know was different. Confirming the restore in the data is quicker and far more conclusive than inferring it from the site's behaviour. - **Mailbox**: let the mail client finish a full sync before judging it. Messages may land in a dated folder rather than in the folder they came from. - **Nothing happened at all**: give it longer before repeating the action. Large sites take longer, and ISPConfig will not stack a second restore on top of a pending one: click **Restore** again while a job is queued and the panel tells you there is already a pending backup restore job rather than starting another. If the site is still wrong after a verified restore, resist the urge to work backwards through older backups. Each attempt destroys the state left by the previous one. Stop, and open a ticket while you still have the copies you downloaded. [How to Monitor Website Usage and Logs in ISPConfig](/ispconfig/how-to-monitor-website-usage-and-logs-in-ispconfig/) shows where the error logs are, and they usually name the real problem in one line. ## When the Backup You Need Has Aged Out ISPConfig keeps a fixed number of backups per site and per mailbox, set by **Number of backup copies**. Once that many exist, each new backup deletes the oldest, permanently, from both the disk and the panel's records. Multiply the copy count by the interval and you have your real window: ten daily copies is ten days, four weekly copies is roughly a month. Nothing older than that window is recoverable through the panel, and no amount of clicking will bring back a row that is no longer listed. To see where you stand before you need to know, open **Statistics** in the left menu of the **Sites** module and click **Backup Stats**. The **Email** module has its own **Backup Stats** under **Statistics** for mailboxes. Both pages show the interval and the copy limit together in one column, then the number of backups that actually exist and the space they use, so you can see at a glance how much of your allowance is filled. The figures are read when you open the page rather than from a nightly snapshot, so a backup that has just finished is counted straight away. ![The Backup Stats page under Statistics in the ISPConfig Sites module, listing each domain with its backup interval, backup count and backup size](/images/kb/217_ispconfig-backup-stats-statistics.png) If what you need is already outside that window: - **Open a ticket straight away rather than after investigating.** Do not wait until you have finished working out what happened. Options narrow with time on a hosting server, so the sooner Noiz support hears from you, the more there is to work with. Say which domain, mailbox or database, what date you need, and what changed. - **Stop making changes to the affected site or mailbox.** Every backup run, and every manual backup, pushes the retention window forward and deletes one more old copy. Leave it alone until you have an answer. - **Look for copies that are not ISPConfig's.** Application-level backups are separate from the panel's and often reach further back: a WordPress backup plugin's own archives, an installer's backups, an export you took before an upgrade, or an old copy in a folder on the server. A previous host's final backup is also worth chasing if the site was migrated. - **Then fix the window so this cannot repeat.** Raise **Number of backup copies** on the site or mailbox, and keep periodic copies somewhere that is not the hosting server. A backup that lives only on the machine it protects is not a backup. [How to Back Up Websites, Databases and Mailboxes in ISPConfig](/ispconfig/how-to-back-up-your-websites-databases-and-mailboxes-in-ispconfig/) covers the settings and what your plan allows. ## Troubleshooting **Symptom**: there is no **Backup** tab on the website or mailbox. Backups are a plan feature, and ISPConfig hides the tab entirely when the allowance is not enabled on your account rather than showing it greyed out. The tab also appears on the main website entry rather than on subdomain or alias entries, which is normal: their files sit inside the parent site's directory and travel with the parent's backup. If you expected backups on your plan and the tab is absent, open a ticket rather than assuming it is broken. **Symptom**: the **Backup** tab is there but **Existing backups** is empty. Nothing has been captured yet. Either **Backup interval** is set to **No backup**, or it was only just switched on and the first overnight run has not happened. An empty list is a correct result, not a fault. For a website you can fill it immediately with **Make backup of web files**; a mailbox has to wait for its next scheduled run. **Symptom**: you need one file or one database table back, not the whole thing. The panel cannot do this, and restoring everything to get one file back would undo far more than you intend. Click **Download** on the backup instead, collect the archive over FTP, open it on your own machine, and upload just the file you want. For a single table, open the downloaded database dump in a text editor, copy out the statements for that table and run them in phpMyAdmin. [How to Connect to Your FTP Account Using FileZilla](/server-administration/how-to-connect-to-your-ftp-account-using-filezilla/) covers the transfer. **Symptom**: no **Download** button on a row that has a working **Restore** button. Downloading is only offered where the backup is held on the same server as the site. Restoring still works. If you need the archive itself rather than a restore, ask Noiz support to retrieve it for you. **Symptom**: the restore reports that it started but nothing changes. Wait longer than feels reasonable, since a large site takes many minutes, then reload the site in a private window to rule out browser caching. Check whether your application has its own cache layer that is still serving the old pages. If a plugin, extension or edge cache sits in front of the site, clear it before concluding the restore failed. **Symptom**: the site is broken in a new way after a restore. The usual cause is a mismatch, not a bad backup: restored files against a current database, or a restored database against current files. Restore the matching partner from the same date. If you restored files only and the site now reports a database connection error, the restored configuration file is holding older credentials that no longer exist. **Symptom**: files you expected to survive are gone after a website restore. This is the restore working as designed rather than a failure. A website restore mirrors the archive over the site directory, so anything added since the backup date is removed. Recover it from the copy you downloaded beforehand. If you did not take one, open a ticket promptly and stop making further changes to the site. **Symptom**: restored email appears in an unfamiliar folder, or messages are duplicated. Both are expected. Restored mail may arrive in a separate dated folder depending on how the server stores mail, and messages present both in the mailbox and in the backup can end up twice. Let the mail client complete a full sync before tidying anything up, and delete duplicates from the client rather than restoring again. ## Related Guides - [How to Back Up Websites, Databases and Mailboxes in ISPConfig](/ispconfig/how-to-back-up-your-websites-databases-and-mailboxes-in-ispconfig/) - [How to Log In to the ISPConfig Control Panel](/ispconfig/how-to-log-in-to-the-ispconfig-control-panel/) - [How to Create a Website in ISPConfig](/ispconfig/how-to-create-a-website-in-ispconfig/) - [How to Create a Database and Database User in ISPConfig](/ispconfig/how-to-create-a-database-and-database-user-in-ispconfig/) - [How to Create an FTP Account in ISPConfig](/ispconfig/how-to-create-an-ftp-account-in-ispconfig/) - [How to Monitor Website Usage and Logs in ISPConfig](/ispconfig/how-to-monitor-website-usage-and-logs-in-ispconfig/) If you are not certain a restore is the right move, ask before you click rather than after. Open a ticket from your Noiz client area with the domain, mailbox or database name, the date you are thinking of restoring to, and what went wrong, and the support team will tell you whether a restore will fix it. Asking costs nothing, and it is the only part of this process that can still be taken back. On Noiz managed plans the team can carry out the restore for you, take the safety copies first, and check the result afterwards. --- Source: https://docs.noiz.ie/ispconfig/how-to-restore-a-backup-in-ispconfig/