Website backup and monitoring

• Website Security
• Updated: 4 October 2026
• About 10 min read

The four parts of the routine

1. 1

   Back up files and database together

   A website is made up of two parts: the files (code, theme, uploaded images) and the database (content, orders, users). Backing up only one of them will not bring the site back. Take copies of both from the same point in time; do not forget the configuration files and, if there are any, the scheduled task definitions.

   : Enlarge

2. 2

   Apply the 3-2-1 rule

   Three copies, two different media, one copy in another location. For a website this means the backup must not sit only on the same server. If the server is compromised or the disk fails, a backup on the same server is lost too. For the details of the rule, see the guide Ransomware and the 3-2-1 backup rule.

   : Enlarge

3. 3

   Try a restore

   You only find out whether a backup is any use by restoring it. At regular intervals, set the backup up in an empty test environment: does the site open, is the database complete, how long did it take? The first drill usually reveals a missing piece; finding that out on a quiet day is better than finding it out in the middle of a crisis.

   : Enlarge

4. 4

   Monitor: notice early

   Automatically monitor whether the site is up, whether files have changed and whether the search engine has seen a problem. The aim is not to monitor everything but, when there is a problem, to find out about it before your customers do.

   : Enlarge

Signs that your routine is incomplete

• You do not know when the latest backup was taken or where it is kept.
• Backups sit only on the server that hosts the site, or in the web root.
• A restore has never been tried.
• Only the files or only the database are being backed up.
• It is your customers who tell you the site is down.
• There is no way of finding out when a file on the server was changed, or by whom.
• Access and error logs are switched off or deleted after a few days.

The backup plan

Frequency

The frequency is determined by how much data you can afford to lose. On a site that takes orders, it is reasonable to back up the database at least once a day (more often on busy sites) and the files daily or weekly. For a brochure site whose content rarely changes, a weekly backup may be enough. Before a major update, take a manual backup as well.

Retention period

Keeping only the latest backup is not enough: an attack may go unnoticed for weeks, and the most recent backups may contain the malicious files too. Set up a tiered scheme that keeps daily backups for one to two weeks, weekly ones for a few months and monthly ones for longer.

Location and security

• Do not keep backups in the web root; anyone who guesses the address can download them.
• Keep at least one copy off the server (another server, cloud storage).
• If the account that writes to the remote store has no permission to delete, the old backups are protected even if the server is compromised.
• Backups contain customer data; encrypt them and restrict access.

Database backup

You can use your hosting panel's backup tool or the mysqldump command. Do not type the password on the command line; keep it in an option file that only you can read.

# Database backup (the password is in ~/.my.cnf, permissions 600)
mysqldump --single-transaction --routines --default-character-set=utf8mb4 \
    ornek_db | gzip > /home/kullanici/yedek/db-$(date +%F).sql.gz

# File backup (written OUTSIDE the web root)
tar -czf /home/kullanici/yedek/dosya-$(date +%F).tar.gz -C /home/kullanici public_html

# Delete local backups older than 14 days (the remote copy is kept separately)
find /home/kullanici/yedek -name "*.gz" -mtime +14 -delete

The restore drill

1. Prepare an empty test environment (a subdomain or your local computer); it should be closed to search engines and visitors.
2. Extract the file backup, import the database backup and adjust the configuration for the test environment.
3. Browse the site: do the pages, images, login and forms work? Are the most recent records there?
4. Note the time it took and the gaps you came across; write the steps down in a short document.
5. Close the test environment; do not leave a copy containing customer data lying around.

Repeat the drill at least once or twice a year and whenever your backup method changes.

File integrity monitoring

Attackers very often modify an existing file or slip a new file in among the others. Recording the hashes of your files at a known clean point and comparing them regularly makes these changes visible. The example below compares the SHA-256 hashes of the PHP files with the previous list and reports any differences.

<?php
// Run from the command line: php butunluk.php
// The script and the list are kept OUTSIDE the web root.
$kok   = '/home/kullanici/public_html';
$liste = __DIR__ . '/ozetler.json';

$simdiki = [];
$gezgin = new RecursiveIteratorIterator(
    new RecursiveDirectoryIterator($kok, FilesystemIterator::SKIP_DOTS)
);
foreach ($gezgin as $dosya) {
    if ($dosya->isFile() && preg_match('/\.(php|phtml|js|htaccess)$/i', $dosya->getFilename())) {
        $simdiki[substr($dosya->getPathname(), strlen($kok))] = hash_file('sha256', $dosya->getPathname());
    }
}

$onceki = is_file($liste) ? (json_decode((string) file_get_contents($liste), true) ?: []) : [];
$yeni      = array_keys(array_diff_key($simdiki, $onceki));
$silinen   = array_keys(array_diff_key($onceki, $simdiki));
$degisen   = array_keys(array_filter(
    array_intersect_key($simdiki, $onceki),
    fn ($ozet, $yol) => $ozet !== $onceki[$yol],
    ARRAY_FILTER_USE_BOTH
));

if ($onceki !== [] && ($yeni || $silinen || $degisen)) {
    $rapor = "New:\n" . implode("\n", $yeni) . "\n\nChanged:\n" . implode("\n", $degisen)
           . "\n\nDeleted:\n" . implode("\n", $silinen) . "\n";
    echo $rapor;
    // Email the report to yourself here.
}
if ($onceki === [] || in_array('--guncelle', $argv, true)) {
    file_put_contents($liste, json_encode($simdiki, JSON_PRETTY_PRINT));   // save the clean state
}

• Keep the script and the hash list outside the web root; run it once a day with a scheduled task (cron).
• Refresh the list after updates you make yourself; otherwise every update will raise an alert.
• A new PHP file is never expected in upload folders; monitor these folders separately.
• If you use version control, comparing the files on the server with the copy in the repository does the same job.
• While the integrity list is on the server, an attacker can change that too; keep a copy of it off the server.

Logs

After an incident, the answer to "what happened, and how did they get in?" is in the logs. Without logs the entry point cannot be found and the same vulnerability is used again.

• Access log: The time, address, source and response code of every request. Check in the hosting panel that it is switched on and how many days it is kept; keep it for at least a few weeks if you can.
• Error log: PHP and server errors. A run of unusual errors may be a sign of someone probing.
• Application log: Successful and failed logins, password changes, administrator actions (who changed what, and when).
• FTP and panel logs: Which account connected, and from where?

What to look for in the logs: POST requests to PHP files you do not recognise, sources that receive a large number of 404 or 403 responses in a short time, heavy requests to the login address, administrator logins at unusual hours. Do not write passwords, card details or more personal data than necessary to the logs.

<?php
// A simple record of security events: who, what, from where, when
function olayKaydet(PDO $pdo, string $olay, ?int $kullaniciId = null, string $ayrinti = ''): void
{
    $sorgu = $pdo->prepare(
        'INSERT INTO guvenlik_gunlugu (zaman, olay, kullanici_id, ip, tarayici, ayrinti)
         VALUES (NOW(), ?, ?, ?, ?, ?)'
    );
    $sorgu->execute([
        $olay,
        $kullaniciId,
        $_SERVER['REMOTE_ADDR'] ?? '',
        mb_substr($_SERVER['HTTP_USER_AGENT'] ?? '', 0, 250),
        mb_substr($ayrinti, 0, 500),   // passwords and card details are NEVER written
    ]);
}

// Usage
olayKaydet($pdo, 'giris_basarisiz', null, 'email: ' . $eposta);
olayKaydet($pdo, 'parola_degisti', $kullaniciId);
olayKaydet($pdo, 'yonetici_eklendi', $kullaniciId, 'new administrator ID: ' . $yeniId);

Uptime and external monitoring

• Uptime monitoring: Use a service that checks the site from outside at regular intervals and sends an email or SMS when it cannot be reached. Checking not only "does it respond" but also whether an expected piece of text is present on the page means you are alerted when the site's content has been altered as well.
• Google Search Console: Verify your site and keep email notifications switched on. The "Security issues" report warns you when Google sees malicious content or signs of compromise on your site. Content that is not yours among the indexed pages is another sign.
• Certificate and domain expiry: Keep an eye on the expiry dates of the SSL certificate and the domain name; even with automatic renewal on, they may fail to renew because of a payment or validation problem.
• Backup reports: Have the success or failure notification of the backup job delivered to you; a backup that fails silently is the most common problem of all.
• Disk space: A full disk stops both the site and the backups.

Checklist

• File and database backups are taken automatically; the frequency matches your tolerance for data loss.
• At least one copy is off the server; backups are not in the web root.
• There is tiered retention; it is not only the latest backup that is kept.
• A restore has been tried at least once and the steps have been written down.
• The result of the backup job is reported to you.
• File changes are monitored; there is a copy of the hash list off the server.
• Access, error and application logs are switched on and kept for long enough.
• Uptime monitoring and Search Console notifications are on.
• Certificate and domain expiry dates are being tracked.

Frequently asked questions

Related guides

• What is ransomware? The 3-2-1 backup ruleHow to protect yourself against ransomware, the 3-2-1 backup rule and what to do during an attack.
• What to do if your website is hackedStep-by-step incident response: maintenance mode, evidence, passwords, clean-up, entry point, restore and notifications.
• Server and hosting securitySFTP/FTPS, file permissions, directory listing, error display, sensitive files and database access.
• Website security checklistWeekly, monthly and yearly tasks; every item links to the relevant guide, and the list is printable.