📑 Table of Contents

    Deleting the wrong folder, overwriting the wrong file, or removing a plugin and taking its data with it — all of these are common and all of them are solvable. But the order of your reaction matters: a wrong move can turn a recoverable loss into a permanent one.

    1. Be clear about what you deleted

    What to do depends entirely on the type of loss. First work out which situation you're in:

    • A file was deleted (an image, a theme file, a document) — lost on the file system. It can be extracted from a file backup.
    • Content was deleted (a post, page, product, order) — lost in the database. You need a database backup.
    • A setting disappeared — usually in the database; reinstalling the plugin will not bring the settings back.
    • The site won't load at all — this is usually not a deletion but corruption or a configuration problem. We cover it separately below.

    ⚠️ Don't create new content in a panic

    Uploading a replacement for the deleted file straight away, or rewriting the deleted post, creates a conflict after the restore. Decide on the recovery route first, then start creating again.

    2. Rule out the easy possibilities first

    Before reaching for a backup, check the following; the loss is often smaller than it looks:

    • The trash: In many content management systems, deleted posts and pages sit in the trash for a while.
    • Revision history: If the content wasn't deleted but wrongly edited, you can go back to an earlier version.
    • Browser cache or an open tab: If the page is still open in a tab, you can take the text from there.
    • Search engine cache: The text of a published page may still be cached.

    3. A single file, or a full restore?

    This distinction is critical, and most people needlessly choose the bigger option.

    Single-file recovery: If only an image, document or theme file is missing, there is no need to restore the whole site. You can view the contents of the backup and download just that one file , then put it back. The site keeps running and no new data is lost.

    Full restore: If content in the database is missing (a post, product or order) the situation is different. A database restore replaces the site's current state with the state in the backup: everything created after the backup is rolled back too. That's why doing a full restore to recover a single post is usually the wrong choice.

    💡 A middle way: open the backup somewhere else

    If you need to recover a single record from the database, instead of writing the backup over the live site, restore it into a separate database , take the record you're after from there and move it into production by hand. That way you don't lose the orders and content in between.

    4. If "the site won't load at all", check this first

    If the site doesn't load at all, that is usually not data loss. The three most common causes:

    • A database connection error: The username, password or host address in the configuration file is wrong. The data is untouched; only the connection is broken. This is common after a server move.
    • A PHP error: A plugin or theme update may have broken the site. Disabling the offending component is enough.
    • A full disk quota: When the server runs out of space the site can no longer write and may show a blank screen.

    In all three cases your data is intact. Restoring in a panic can cause you to lose data you hadn't actually lost. Diagnose the cause first.

    5. The lasting fix: have a point you can go back to

    The only thing that decides these cases is how far back your backups go. If you notice the mistake a week later and your backups are only kept for three days, you have backups — but they are of no use to you.

    • Decide the retention count yourself: Decide how many copies of each backup type to keep; for mistakes noticed late this is what matters.
    • Be able to look inside the backup: Being able to view the contents before downloading lets you pick the right backup.
    • Be able to extract a single file: Don't be forced to restore the whole site for a small loss.

    In Yedekalma you can view the contents of a backup from the panel and download a single file or folder — for the details see the database backup and backup verification pages.

    Frequently Asked Questions

    Can I recover a file I deleted by mistake without restoring the whole site?

    Yes. If the loss is a single file (an image, a document, a theme file), it is enough to view the backup's contents and download just that file. The site keeps running and no data in between is lost. Restoring the whole site is only necessary for widespread losses.

    How do I get back a deleted post or product?

    That content lives in the database. Check the trash and the revision history first; it is often there. If not, you need to recover it from a database backup. Because a full restore rolls back every change in between, it is better to open the backup in a separate database, take only the record you need and move it into production by hand.

    My site won't load at all — have I lost my data?

    Most likely not. There are three common causes and in all of them the data is intact: wrong database connection details in the configuration file, a plugin or theme update breaking the site, and a full disk quota. Always diagnose the cause before you restore.

    If I restore, will I lose the orders in between?

    A database restore replaces the site's current state with the state in the backup; orders and content that arrived after the backup are rolled back. That is why a full restore for a small loss is usually the wrong choice. Try the single-record recovery routes first.

    If I notice the mistake late, will my backup still help?

    Only if your backups go back that far. If retention is short (three days, say) and you notice the mistake a week later, every backup you hold already contains the broken state. That is why deciding how many copies of each backup type to keep, based on your own needs, matters.