Everything you need to know about BlaqPanel backups (server backups & site backups).
Setting up AWS S3:
Why we recommend AWS S3 for remote backup storage:
- If you don’t already have an AWS account, sign up for one here. You’ll have to a wide variety of useful cloud services, all enterprise-grade and priced very competitively with other brands.
- S3 is Amazon’s cheap online storage service. It’s very cheap, can store a couple hundred GB’s for about a couple dollars/month (don’t quote me). You should always save backups remotely (and not on the server) in case your server ever gets compromised, hacked, destroyed, and/or your other backups don’t work. I absolutely love backing up everything to S3 and it’s saved my @$$ so many times.
Creating an S3 bucket:
- Go to the S3 page after logging into your AWS account. It’s probably this link.
- Then create bucket.
- I suggest an easy name to remember, but descriptive of the backups in there (e.g. “terra-server-backups”).
- I suggest picking a location closest to your server location. If you’re backing multiple servers to this bucket, then choose a bucket location somewhat central to the servers so all of them can transfer to it relatively quickly.
Generating AWS S3 Credentials:
- After you log into AWS, click on [YOUR NAME] at the top-right, and then My Security Credentials.
- Then click on Access keys (access key ID and secret access key) and [Create New Access Key].
- The access key and secret access key are only shown once, so save it somewhere. And you’ll probably be entering it into other apps and things later on. If you lose it, you’ll have to generate a new one (which automatically disables your old one) and cause you to have to update the AWS credentials everywhere that you used it. So annoying, I know…so don’t lose it!
- PRO TIP: if you want to do things the pro way, look up IAM users and how to use them. For our use though, AWS S3 keys are more than adequate.
Configuring server backups
All this is seen from your Server settings > Backup TAB.
AWS S3 Credentials:
- Enter your AWS access keys and bucket name.
- This bucket will serve as the default bucket. It will be used if you don’t specify an alternate bucket anywhere else.
Automatic Backups:
Backups are run automatically each day around UTC 06:00.
- AWS Bucket name – you can choose to specify one just for your automatic server backups, or let it use default.
- Retention Days – the number of backup days saved on the local server. Putting “7” days means it will save 7 days of backups on the server. Obviously if you have huge sites on the server, you should put something less. Ideally, your sites would only be taking up 20-35% of your server space (so you have room to generate and save local backups).
- Delete Remote Backups – this feature is disabled by default (which is recommended option IMO). This means it will never delete backups off your remote S3 storage bucket. If you enable it then, it will save the same number of backups on both your local and remote storage (automatically deleting remote ones when it deletes local ones).
- Schedule – set this to Enabled to start your automatic backup schedule.
Delete Backups:
- This will only delete all local backups. Useful if you want to clear up space.
Prune Backups:
- This will only delete all local backups OLDER THAN the retention day setting above. So if you put in “3”, it will delete all local backups older than 3 days.
Configuring site backups
All this is seen from your Site settings > Backup & Restore TAB.
Manual Backup:
- Use this to create a manual site backup right there on the spot. Useful to do before you make big (or risky) changes to your site.
- You can use the default AWS bucket or specify a different one.
Automatic Backups:
- AWS Bucket name – you can choose to specify one just for your automatic site backups, or let it use default bucket (specified in server backup settings).
- Retention Days – the number of backup days saved on the local server. Putting “7” days means it will save 7 days of backups on the server. Obviously if you have huge sites on the server, you should put something less. Ideally, your sites would only be taking up 20-35% of your server space (so you have room to generate and save local backups).
- Delete Remote Backups – this feature is disabled by default (which is recommended option IMO). This means it will never delete backups off your remote S3 storage bucket. If you enable it then, it will save the same number of backups on both your local and remote storage (automatically deleting remote ones when it deletes local ones).
- Schedule – set this to Enabled to start your automatic backup schedule.
Restore Backup:
- First [Refresh Backup List] to see the available backups to restore. It scans only for local backups. To restore from a backup on S3, you must move it to the
/root/.wp-backup/
directory on the server. - Choosing to restore Full Backup restores everything.
- Choose to restore only .htaccess or wp-config.php would restore only those files and nothing else.
Delete Backups:
- This will only delete all local backups. Useful if you want to clear up space.
Prune Backups:
- This will only delete all local backups OLDER THAN the retention day setting above. So if you put in “3”, it will delete all local backups older than 3 days.
Plugin backups
Install BackWPup plugin.
- This is not through our control panel, but a WordPress plugin. You should do it to have multiple layers of backups (in case one fails).
- Install BackWPup plugin (it’s free).
- You can also buy the paid version if you want the extra features. It’s not necessary, though.
- In case you’re wondering, I like BackWPup so much more than UpDraft Premium backup plugin.
Setting up full backups (with BackWPup):
- Go to WP-admin > BackWPup > Add new job.
- From General tab, check “Database backup” and “File backup”. Then scroll down to Job Destination and check “Backup to an S3 service.”
- From Schedule tab, choose “WordPress cron” and pick weekly.
- From DB Backup tab, click “All” for Tables to backup.
- From “To: S3 Service” tab, click the “Select a S3 service” dropdown and pick a location near the web-server, then enter Access/Secret keys. Select a bucket or create a new bucket.
- For file deletion, I suggest “8” to save eight weeks worth of full site backups.
- Click “Save changes” at the bottom. Then go to BackWPup > Jobs, and run the job to make sure that it works.
Setting up database backups (with BackWPup):
- Go to WP-admin > BackWPup > Add new job.
- From General tab, check “Database backup”. Then scroll down to Job Destination and check “Backup to an S3 service.”
- From Schedule tab, choose “WordPress cron” and pick daily.
- From DB Backup tab, click “All” for Tables to backup.
- From “To: S3 Service” tab, select your bucket location (if you have one), then enter Access/Secret keys. Then select your bucket or create a new bucket.
- For file deletion, I suggest “30” to save thirty days worth of database backups.
- Click “Save changes” at the bottom. Then go to BackWPup > Jobs, and run the job to make sure that it works.
Restoring backups (manually)
- Usually backups are restored easily through our control panel, or backup plugin (if that’s what you used). But sometimes the restore doesn’t work for whatever reason (PHP timeout, it’s too big, you only need a partial restore, etc). These are the steps how to do it in full. And of course, you can skip or alter steps as needed.
- Delete all files and folders inside the website directory you’re restoring for.
- Go to phpMyAdmin, select the database of the website you’re restoring, select all tables, and choose “DROP” to drop all tables. Then click “Import” at the top and upload the backup of the old database to restore it.
- Upload the backup archive onto your website directory (using either File Manager or SFTP) and extract it so all files are in the same place as before. This is assuming you’re restoring backups to the same place it was backed up from. If you’re restoring to a different server or account, you might have to alter the database credentials in wp-config.php and maybe edit/remove stuff in .htaccess as well.
- Everything should be working now.
More backup tips:
- Yes, although full backups already include the database, I still recommend doing separate database backups (from backup plugin) in case you realize later that your full backups never ran or didn’t backup properly. (It happens!)
- I generally don’t recommend DAILY full backups for websites unless your site is small (1GB and below) AND you’re making changes often or having sales everyday. I wouldn’t save more than 7 days worth of daily backups.
- Big sites (over 2GB) can do full backups every week (Sunday or any day/time with low traffic would be the most logical idea). I wouldn’t save more than 8 recent instances (two months) worth of weekly backups. Big sites should never do do daily backups as that eats up too much server resources and can take forever if the server is especially big.
- EVERY site regardless of size (big or small) should save 6 months of FULL MONTHLY backups. WHY?! This is because your site may be hacked or something was broken or had so change and it actually happened months ago but you didn’t realize until recently. In this case, having an old enough backup would be a very helpful reference point to get back to.
- Really large sites (above 5GB) should really only be doing incremental backups anyway! Or least exclude some files/folders so you’re not unnecessarily wasting so much space saving stuff that never changes.