Regular backups and disaster recovery planning.

[Shortie]

If you are someone who has been running websites for many years, you will know how important both regular backups and having a plan should a disaster arise are.

Keeping regular backups is always advised as you never know when you could hit a problem such as cyber threats, natural disasters, hardware failures and even human errors and they can strike at any point with no warning.

Do you have a disaster recovery plan if anything happens and how do you handle your backups to ensure you do not lose any data?

 

[joelr]

On my primary website, I did set up a remote backup in another country on another host, in addition to a standard backup in the same server. It's a balance between cost and need. Being more secure in your backups
adds cost, and asking at what point does it become worthwhile to implement?

 

[Ravenfreak]

I need to get better at making my own backups. I know my host does backup my sites, however you just never know when disaster will strike and it's really best to make your own backups as well.

 

[Tracy]

Being more secure in your backups
adds cost, and asking at what point does it become worthwhile to implement?

Actually you can do secure backups without any out of pocket additional costs incurred. Just takes a little scripting to pull those backups into other locations using free tools like rsync and similar.
Creating a bash script to perform the backups and keep a rolling 7 day set on the server takes about 3 minutes of time.
The below works well if you don't mind the dump file being in a subdirectory off the web root for a short period of time. It creates a SQL dump file and then also does a full archive of the entire web directory, including the SQL dump file. After creating the archive it then deletes the SQL dump file to save space.
It's easy enough to keep outside sources from being able to discover/access the SQL by your web browser control file, especially if you place it in a subdirectory in the web root.

#!/bin/bash
####################################
#
# Rolling 7 day backup to local directory
#
####################################

mysqldump_location="path_to_place_mysql_dump_file"

/usr/bin/mysqldump --opt your_database_name --single-transaction --default-character-set=utf8mb4 > $mysqldump_location/your_dump_file_name.SQL

# What to backup.
backup_files="path_to_your_website_directory"

# Where to backup to.
dest="path_to_place_your_backup_files"

# Create archive filename.
day=$(date +%A)
hostname=$(hostname -s)
archive_file="your_domain_name-$day.zip"


# Backup the files using zip.
zip -r $dest/$archive_file $backup_files
rm -f $mysqldump_location/your_dump_file.SQL

With nginx it's easy enough to protect that sub-directory with using a location directive in your main site config

location /yourdumplocation/ {
    internal;
 }

You can then automate your routine to use SFTP to access them or rsync if you are running a VPS/dedi.
This script does depend on mysqldump being available for your use as well as the archiver. Some shared hosts will probably not allow this script to work and it's more tailored towards a VPS/dedi install as that's all I have used for about the last decade.

 

[Baw$e]

I've had to restart many times, it sucks losing a huge database with content, and members.