-
Notifications
You must be signed in to change notification settings - Fork 1k
How to make a backup
A backup is useful only if it contains everything needed for recovery, is stored away from the live server, and has been tested. Make a backup before updates, plugin resets, storage changes, database work, or server migration.
| Item | Why it matters |
|---|---|
| Database | Users, videos, settings, permissions, playlists, and plugin records |
videos/configuration.php |
Database connection, site URL, paths, and installation-specific configuration |
| Media files | The actual videos, audio, images, subtitles, and generated output |
| Custom or paid plugins/themes | They may not be recoverable from the public repository |
| Custom CSS/JavaScript and server configuration | Required to reproduce the site's behavior and routing |
| Encoder configuration, if separate | Required to reconnect and reproduce output profiles |
The normal configuration file is inside the AVideo videos directory, for example:
/var/www/html/AVideo/videos/configuration.php
Your installation path may differ. Check systemRootPath in that file instead of assuming /var/www/html/AVideo.
If you use S3, B2, FTP storage, CDN storage, AVideo Storage, or another mount, confirm whether the backup includes the remote objects. Exporting only the AVideo database does not copy remote media.
CDN Storage provides managed remote capacity, and CDN can reduce repeated delivery traffic from the origin. Neither replaces a backup: keep a separate recovery copy.
The videos/cache directory can normally be rebuilt and does not need to be included. Do not exclude the whole videos directory: it contains configuration.php and may contain the media itself.
- Record the AVideo version, plugin versions, installation path, and storage providers.
- Avoid uploads, encoding completion, and configuration changes during the database/file snapshot.
- Export the database with a database-aware tool such as
mysqldump. - Copy the required files while preserving names, paths, and permissions.
- Copy the completed backup to separate storage.
- Encrypt the backup if it contains credentials or personal data.
- Record the backup date and retention policy.
- Test restoration in a separate environment.
Do not paste a database password directly into a command that will be saved in shell history. If you do not manage the server, ask the hosting provider to create a consistent database and file snapshot.
The Backup Plugin can automate parts of the process. A file produced inside the same live server is still vulnerable to the same disk failure, compromise, or accidental deletion. Copy completed backups off the server and monitor whether scheduled backups actually finish.
| Tool/page | Best use | Important check |
|---|---|---|
| Backup Plugin | Automate a database dump and supported site/video archive | Copy the completed result away from the live server |
| Clone Site Plugin | Duplicate a compatible site when the installed formats/plugins support that workflow | The older guide excluded VideoHLS; verify current compatibility before relying on it |
| Storage Options | Understand where media actually lives | Remote storage, replication, and backup are different protections |
Restoring is more than copying the videos directory:
- Prepare compatible web-server, PHP, database, and FFmpeg versions.
- Restore application/custom files and media to the expected paths.
- Restore the database.
- Restore or carefully adapt
videos/configuration.phpfor the new URL, paths, and credentials. - Restore required server configuration and scheduled tasks.
- Check file ownership and writable directories without using broad
chmod 777permissions. - Clear generated cache.
- Test administrator and normal-user login, playback, upload/encoding, email, scheduled tasks, private content, and critical plugins.
If restoring to a different domain or directory, also follow Change the Installation URL.
- Saving the backup only on the live server
- Exporting the database but not media or configuration
- Copying media but not the database
- Assuming remote storage is automatically versioned or backed up
- Never testing restoration
- Keeping secrets in an unencrypted public folder
- Running out of disk space while creating a local archive