Jump to content

Epoch Linux Server Backup


drewappling

Recommended Posts

Hello,

 

After searching for an adequate backup solution for my Epoch server and not finding something that met my personal criteria I decided to see what could be done using bash scripts and Google drive, below is what I came up with, it works pretty well so far. The full backup of the server files takes quite a bit of time to upload so I recommend doing this only when needed.

 

Here's what I've come up with, this backup consists of four pieces; grive, mysqldump script, epoch server files backup script and cron, I haven't had a chance to setup the cron jobs for this yet but test them and verified that they work. The epoch server files backup is simply a script that zips the files and saves it to the folder grive is synchronizing with.

 

My Epoch server is running on Ubuntu 14.04 so your configuration may vary. 

 

Install and setup Grive:

 

sudo apt-get-repository ppa:nilarimogard/webupd8

sudo apt-get update

sudo apt-get install grive

 

mkdir google_drive

grive -a

 

After typing grive -a you will be prompted to enter an authorization code, copy the output from the grive -a command to a web browser, sign into google and authorize grive, once this is complete you will need to paste in the authorization string, you can run the command grive to synchronize the folder with google drive.

 

Mysql backup:

This is a copy of a script that I found online, it worked perfectly. At the end of the script I added the grive command to sync the folder with google drive, enter your user, password, host and database name. The script can be run as a cron job, since everything is running under my home folder sudo is not required.

 
#!/bin/bash
 
user=""
password=""
host='192.168.1.121'
db_name="epoch"
 
backup_path="/home/epoch/grive/mysqlbackups"
date=$(date +"%d-%b-%Y")
 
# Set default file permissions
 umask 177
 
# Dump database into SQL file
 mysqldump --user=$user --password=$password --host=$host $db_name > $backup_pa$
grive
done
 
Link to comment
Share on other sites

  • 1 month later...

2kohm: you do not backup the cache files from the servers directory?

 

I backup my files in restarter.pl when the server is shutdown.

I do a mysql-dump as well as archiving the corresponding cache files just before the server restarts.

 

Did you ever try to delete everything and restore a backup? I have a lot of customers who know exactly how to do a backup. But they never tried a restore process and recognize that at the time they really need it ,)

Link to comment
Share on other sites

The cache isn't used for 'caching' in the traditional sense. It is a means to communicate the database values to the game engine: the writer script in response to certain child statements writes SQF files that the server evaluates, importing the code (data) in them and therefore making it accessible to the scripts. You shouldn't back it up and it's actually a good idea to clear it during the server restart, because of an obtuse logical bug that uses the number of players as the "current" cache pointer and as a result you may spawn in a different position or with a different gear from what you'd expect. 

 

On a side note, the common wisdom in professional system administration is that "there is no backups, only recovery." If you have not verified that your backup strategy will actually recover from disaster, that's basically russian roulette.

Link to comment
Share on other sites

Did you try that? When I've tested this long ago I did not carry the same inventory anymore and things got worse.

And exactly that happened what you mention above. You end up somewhere else and things like that. Maybe I've tested this wrongly at a time I did not yet understand the reason for the /cache/ dir...and never tried it out since then ;)

Maybe that's fixed now. When I started at the begin of the year with the linux version there was a discrepancy between DB values and cache files.

I guess if you delete the cache dir you end up ALWAYS as a default player/character.

Need to have a look into writer.pl again...but that was how it was before if I remeber correctly.

Link to comment
Share on other sites

The reason this happens is that when the server is terminated, the current cache is not cleared. As the current cache directory name equals the current number of players N, and the number resets to 1 when you restart the server, the leftover cache with name N will be read instead of the latest one when Nths player joins the server. 

 

If you wipe the cache, or at least the numbered directors in cache/players, you will not lose your gear or location. 

Link to comment
Share on other sites

  • 3 weeks later...
Here are my scripts for backing up and restoring DayZ SQL database 
 
SQL Backup / Restore scritps
---- sqlbackup ----
 
#!/bin/bash


user="<epoch username>"
pass="<epoch password>"
db_name="<epoch dbname>"
backup_path="/opt/backups/sqlbackups"
date=$(date +"%m-%d_%H%M-%Y")


echo Starting Backup of<sitename>-sql_$date


mysqldump -u$user -p$pass $db_name | gzip > $backup_path/noctemoculus-sql_$date.sql.gz || fail "Unable to backup $db_name"
echo Done!!
----sqlrestore (drop this inside your /opt/backups/sqlbackups directory)----
 
#!/bin/bash
# [email protected]
#


db_user="<admin dbuser>"
db_pass="<admin dbpass>"
dz_user="<epoch username>"
dz_pass="<epoch password>"
db_name="<epoch dbname>"
prompt="Please select the SQL backup you wish to restore:"
options=( $(find *.gz -maxdepth 1 -print0 | xargs -0) )
clear
PS3="$prompt "
select opt in "${options[@]}" "Quit" ; do
if (( REPLY == 1 + ${#options[@]} )) ; then
exit


elif (( REPLY > 0 && REPLY <= ${#options[@]} )) ; then
echo "You picked $opt which is file $REPLY"
break


else
echo "Invalid option. Try another one."
fi
done


gunzip $opt
res=$(ls -t -U | grep -m 1 "noctem"*.sql)
echo Dropping $db_name database
yes|mysqladmin -u$db_user -p$db_pass drop $db_name &gt; /dev/null || fail "Unable to drop $db_name database"


echo Dropping DB user $dz_user from SQL server
mysql -u$db_user -p$db_pass -e "DROP USER '$dz_user'@'localhost';" || fail "Unable to drop $dz_user from SQL server"


echo Creating new $db_name database
mysqladmin -u$db_user -p$db_pass create $db_name || fail "Unable to create the database; invalid user/password?"


echo Dumping $res to new $db_name database
mysql -u$db_user -p$db_pass $db_name &lt; $res || fail "Unable to restore $res to $db_name"


echo Creating new DB user $dz_user on SQL server
mysql -u$db_user -p$db_pass -e "GRANT ALL PRIVILEGES ON $db_name.* TO '$dz_user'@'localhost' IDENTIFIED BY '$dz_pass';" || fail "Unable to Create $dz_user on SQL server"


echo Dabatase $res has been restored !!
gzip $res
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Discord

×
×
  • Create New...