Originally Posted by
Angel That was the point in my post. While backing up the software everyday may be a bit wasteful, the overhead is less than 20MB. Given the price of storage media nowadays, I'd venture to say that this is a trivial amount of data.
Yes, And I guess it make restoring easier too.
Originally Posted by
Angel BTW, I am not sure how the size of that backup would be 26x larger than the MySQL dump. Thats seems a bit strange, unless you have a lot of stuff in the cache folder, in which case, your previous thought of backing up /cache wouldn't help reduce its size.
The gzipped database dump is around 1/4 MB, the gzipped tar of cache and custom dirs is also around 1/4 MB. The gzipped tar of the entire SugarCRM dir is around 6 Mb (and four sixes are twenty-four).
For other systems I have running, I do a daily dump and hourly incremental backups. It looks like SugarCRM will be having only daily backups. I don't even know if I can do incremental backups with MySQL -- I guess I could use diff or something against the previous backup <shrug>
Originally Posted by
chrisky If you'd like to determine which specific files are the ones of which can be customized...
...much removed...
Originally Posted by
chrisky This will give you the information in which you're after..
Thanks. It seems that the areas I'm interested in are:
cache/
custom/
modules/
data/
(and the log file in the root)
This limits the backup to about 1.5 Mb of files
Originally Posted by
chrisky Merry Christmas to all!
Thanks -- and you guys have a good one too.
Steve
p.s. This may be a solution. I have created 3 scripts, Full, Partial, and Incremental backups.
Full -- backs up all data and files (I'll run this once a week)
Partial -- backs up all data and files changed since last full backup (I'll run this daily)
Incremental -- backs up a diff of the data and files changed since the last partial backup (hourly)
There's a problem with the dump of the database. I need to replace "),(" with "),<eol>(", and I do this with sed. If I don't do this, the diffs end up twice the size of the data files when there's changes! I'll need to test that the extra <eol>s doesn't break the SQL (It shouldn't).
Here's the scripts as they are now:
sugar-full-backup.sh
Code:
#!/bin/sh
#
# do a full backup of SugarCRM -- All data, all files
#
dir=/var/backup/sugarcrm/
datum=$(date +%Y-%m-%d__%H-%M-%S__)
fullflag=${dir}.last-full-backup
partialflag=${dir}.last-partial-backup
lastsqlbackup=${dir}lastbackup.sql
#
# touch last backup time
#
touch ${partialflag}
touch ${fullflag}
#
# database backup
#
name=sugarcrm-full-backup.sql
file=${dir}${datum}${name}
/usr/bin/mysqldump sugarcrm --complete-insert -u user -ppassword --flush-logs --opt --add-locks >${file}
sed 's/),(/),\n(/g' <${file} >${lastsqlbackup}
/bin/gzip -f ${file}
#
# backup all files
#
name=sugarcrm-full-backup.tar
file=${dir}${datum}${name}
cd /var/www/sugar
tar -cf ${file} *
/bin/gzip -f ${file}
#
# Transfer to backup storage
#
cd ${dir}
wput -u -R ${datum}* ftp://user:password@server/backup/database/sugar/ sugar-partial-backup.sh
Code:
projector:/etc/backup# cat sugar-partial-backup.sh
#!/bin/sh
#
# do a partial backup of SugarCRM -- All data, files changed since last full backup
#
dir=/var/backup/sugarcrm/
datum=$(date +%Y-%m-%d__%H-%M-%S__)
fullflag=${dir}.last-full-backup
partialflag=${dir}.last-partial-backup
lastsqlbackup=${dir}lastbackup.sql
#
# touch last backup time
#
touch ${partialflag}
#
# database backup
#
name=sugarcrm-partial-backup.sql
file=${dir}${datum}${name}
/usr/bin/mysqldump sugarcrm --complete-insert -u user -ppassword --flush-logs --opt --add-locks >${file}
sed 's/),(/),\n(/g' <${file} >${lastsqlbackup}
/bin/gzip -f ${file}
#
# backup files since last full backup
#
set LAST_UPDATE = `ls -l ${fullflag} | awk '{print "since",$6,$7,$8}'`
name=sugarcrm-partial-backup.tar
file=${dir}${datum}${name}
cd /var/www/sugar
find . -type f -newer ${fullflag} -print >> /tmp/tar$$
tar -cf ${file} -T /tmp/tar$$
/bin/gzip -f ${file}
#
# Transfer to backup storage
#
cd $dir
wput -u -R ${datum}* ftp://user:password@server/backup/database/sugar/ and finally sugar-incremental-backup.sh
Code:
#!/bin/sh
#
# do a incremental backup of SugarCRM -- changed data and files since last backup
#
dir=/var/backup/sugarcrm/
datum=$(date +%Y-%m-%d__%H-%M-%S__)
fullflag=${dir}.last-full-backup
partialflag=${dir}.last-partial-backup
lastsqlbackup=${dir}lastbackup.sql
#
# database backup
#
name=sugarcrm-incremental-backup.sql
file=${dir}${datum}${name}
/usr/bin/mysqldump sugarcrm --complete-insert -u user -ppassword --flush-logs --opt --add-locks >${file}
mv ${file} ${file}x
sed 's/),(/),\n(/g' <${file}x >${file}
rm ${file}x
diff -u ${lastsqlbackup} ${file} > ${file}.diff
/bin/gzip -f ${file}.diff
rm ${file}
#
# backup files since last partial backup
#
set LAST_UPDATE = `ls -l ${partialflag} | awk '{print "since",$6,$7,$8}'`
name=sugarcrm-incremental-backup.tar
file=${dir}${datum}${name}
cd /var/www/sugar.conexio-genomics.com
find . -type f -newer ${partialflag} -print >> /tmp/tar$$
tar -cf ${file} -T /tmp/tar$$
/bin/gzip -f ${file}
#
# Transfer to backup storage
#
cd $dir
wput -u -R ${datum}* ftp://user:password@server/backup/database/sugar/ If I want to recover from an incremental backup, I'll need to use patch, but that's not a huge issue.
Currently a full backup backs up everything (so about 6M + data)
A partial, with no changed files is a 95 byte file and the gzipped data
An incremental with no changes is 2 files, 289 bytes and 99 bytes.
The weakness of this is that the backup doesn't record deleted files, so if you have to restore from a set of backups, you might end up with a few fils that were deleted between the full backup and the partial/incremental backup(s) used.
LinkBack URL
About LinkBacks
Howto? Backup things not in database
Reply With Quote
Re: Howto? Backup things not in database
Re: Howto? Backup things not in database
Bookmarks