Subscribe> The list of potential causes for this disaster is a short one. It includes a catastrophic failure by the operating system (OS X Server, in case you're interested), or a deliberate effort.It's difficult to imagine a way in which the OS would cleanly overwrite an entire hard disk of data. If the OS did it, I would imagine the data left on the disks to look like a car wreck, with many fragments left over.
# DB BACKUP SCRIPT
#############################################################
# ADJUST THE VALUES OF THE FOLLOWING VARIABLES AS NEEDED
#############################################################
#define name of database
SQL_DB_NAME="insert_db_name_here"
SQL_DB_USER="insert_db_user_here"
SQL_DB_PWRD="insert_db_password_here"
SQL_DB_SERV="insert_db_server_here"
#define local path (shouldn't use relative paths in crontab)
LOCAL_PATH="/home/username/htdocs/"
#define remote (sftp) variables
REMOTE_PATH="/home/username/backups/db/"
REMOTE_CONN="username@server.com"
#############################################################
# YOU SHOULDN'T HAVE TO TOUCH ANYTHING BELOW THIS LINE
#############################################################
#define variable with name of file to be used for backup
FILE_NAME="backup_${SQL_DB_NAME}_$(date '+%Y%m%d')"
SQL_FILE_NAME="${LOCAL_PATH}${FILE_NAME}.sql"
ZIP_FILE_NAME="${LOCAL_PATH}${FILE_NAME}.zip"
#get backup from database (server name, db name, password, username)
mysqldump -h${SQL_DB_SERV} -u${SQL_DB_USER} -p${SQL_DB_PWRD} ${SQL_DB_NAME} > ${SQL_FILE_NAME}
#compress backup
zip ${ZIP_FILE_NAME} ${SQL_FILE_NAME}
#send backup to remote location
echo "put ${ZIP_FILE_NAME} ${REMOTE_PATH}" | sftp ${REMOTE_CONN}
#clean up local copies of files
rm -f ${SQL_FILE_NAME}
rm -f ${ZIP_FILE_NAME}
#that's all.
Similar for app except that I cron an rsync to a remote server daily and then have a separate script that compresses the rsync'd mirror daily.zip and sftp is a huge WTF, but at least you're assuming ssh keys are used!mysqldump … | gzip | ssh ${REMOTE_CONN} 'cat > ${REMOTE_PATH}${FILE_NAME}.sql.gz'mysqldump … | gzip > ${LOCAL_PATH}${FILE_NAME} && scp ${LOCAL_PATH}${FILE_NAME} ${REMOTE_CONN}:${REMOTE_PATH}${FILE_NAME}It was the guy handling the IT (and, yes, the same guy who I caught stealing from the company, and who did a slash-and-burn on some servers on his way out) who made the choice to rely on RAID as the only backup mechanism for the SQL server. He had set up automated backups for the HTTP server which contains the PHP code, but, inscrutibly, had no backup system in place for the SQL data. The ironic thing here is that one of his hobbies was telling everybody how smart he was.In conclusion, this guy should be blamed for allowing asshats to run his servers, not for misunderstanding RAID
« Older Some videos: In 1985, Tipper Gore's PMRC released ... | The Internet Bird Collection... Newer »
This thread has been archived and is closed to new comments
It's a redundancy mechanism, not a backup. Raid is not a backup. Repeat till remembered.
posted by bonaldi at 6:23 PM on January 3 [2 favorites]