PHP Website and MySQL Backup

A script backup is a MySQL dump plus a file archive: code, uploads, and config. One without the other is useless: files alone give empty records, and a database alone gives 404 images. Before an update, hosting move, or major admin change, a copy is mandatory.

Keeping a backup on the same disk as the site is better than nothing, but if the VDS dies, everything dies together. Use a second medium, another server, or S3-class storage.

Minimum before an update

1. Dump all tables of the required database.
2. Archive the document root, especially folders such as files/ and upload/.
3. Save the config with credentials separately; it may be overwritten when unpacking a new release.
4. Check that the archive opens, the dump is not zero bytes, and import into a test database works.

Updating without overwriting user data: support and updates.

MySQL dump

mysqldump -u user -p --single-transaction --routines dbname > dump.sql

--single-transaction is convenient for InnoDB. On shared hosting, use phpMyAdmin export or the backup button in Beget/Timeweb/ISPmanager. Large databases often time out in a web interface; then SSH/CLI is the only reliable path.

Use utf8mb4. More about moving dumps: MySQL migration.

Files

tar -czf site-$(date +%F).tar.gz /var/www/site

Or create an archive from the hosting panel file manager. You can exclude cache/ and temporary files if they really regenerate. Never exclude uploads.

Align permissions after restore: chmod.

What counts as a check

"The file is in backups" is not a check. A check means deploying it on a copy of the host or into a separate database and folder, then opening the home page and admin panel. Once a quarter is enough if you fear forgetting. After the first failed restore, you will be grateful.

Schedule

• Daily database dump at night.
• Files daily, or at least uploads daily and code after changes.
• Keep several points: 7 daily copies plus one weekly copy.

Product cron and backup cron are separate tasks. PHP schedules: cron. Make sure old archives do not fill the disk: monitoring.

Before migration

A move to another server starts with a backup, not with deleting DNS. Sequence: script migration. A local copy on MicroServer also works as a training restore: local server, import: phpMyAdmin.

VDS snapshots

A hypervisor snapshot is useful but does not replace a logical dump. A snapshot rolls back the whole machine; restoring one table from it is painful. Keep both layers if the data matters.

Firewall and backup-server access: firewall, VDS.

If you already broke it without a copy

Check provider autobackups; sometimes a daily rollback exists. Do not write huge new files over the disk because the chance of recovery tools drops. Then honestly estimate losses and restore from what exists. Product support: how to write, timelines: SLA.

What exactly goes into the file archive

Required: PHP code if not restored from git, upload folders, config with credentials, .htaccess if Apache is used, and templates if modified. Optional exclusions: cache, temporary thumbnails if regenerated, vendor only if you can run composer install on the target machine.

On shared hosting without SSH, vendor is often archived. On a VDS with Composer, choose what suits the team. Composer: locally; on the server the principle is the same.

Names and rotation

A dated filename helps: board-2026-10-06.sql, board-files-2026-10-06.tar.gz. Keep at least a week of daily copies and one known-good snapshot after a successful release. Delete old files deliberately; otherwise the VDS disk stops at night and monitoring starts screaming for another reason: monitoring.

Restore step by step

1. Deploy files into the site directory, or next to it and switch the root.
2. Create an empty utf8mb4 database and import the dump: migration.
3. Write credentials into the config.
4. Align owner and permissions: chmod.
5. Check the home page, admin panel, and one card with an image.

If images are 404, uploads were missing from the archive or URLs in the database point to another domain. After changing a domain, update site settings. Full move: script migration.

Backup only through the hosting panel

The backup button in Beget/Timeweb/ISPmanager is convenient. Downsides: it is not always clear whether files are inside, how fast you can download it, and how many points are kept. Once a month, download an archive yourself. Do not rely on "they surely have it" on the day of a fire; read the plan retention period in advance.

File and database consistency

If the dump was taken at 12:00 and files at 18:00, the database may already miss files uploaded during the day, or vice versa. Take them close together, preferably during low load. For critical backups, briefly enable maintenance mode if the product supports it.

Encryption and storage

A dump contains all users and sometimes tokens. Store it in a closed directory, on an encrypted disk, not in public www/backups served by Nginx. An exposed backup folder is a gift to scanners. On a VDS, close the path in nginx and filesystem permissions. A firewall alone does not hide a file: firewall.

A local copy on MicroServer is useful for restore practice: local server, import: phpMyAdmin. Installing from scratch after total loss with no backup is just installation and acceptance of data loss.

Do not keep the only backup copy in /var/www/site/backup inside the document root. Nginx may start serving sql files if location rules are wrong. Move it outside root or deny all. Check filenames, dates, and sizes after copying: a zero-byte dump.sql after failed cron is not a backup. Add monitoring for "today's file exists and is larger than N bytes": monitoring. Before a product update, backup is mandatory even for a small patch: updates. Moving to a new server starts with the same discipline: migration, dump. On VDS, remember permissions after restore: chmod.