Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
What to do when something goes terribly wrong. The first step is always prevention so taking a few extra steps now will do wonders when it’s time to recover from some horrible event. Bricolage can be backed up 3 different ways, and depending on your installation and environment, one of them should work for you.
While this may not work for all recovery scenarios it is the best way to grab everything at once and to make sure nothing is missed. I won’t go over the entire clone process, there is plenty of documentation that does that well I will list the pros and cons to it.
- Easy to backup / restore
- Guarantee all data is captured
- Contained in one file
- Not scriptable
- Large backup size
The standard method of backing up should be to backup the database and the media. Since the media is stored outside the database it must be backed up seperately. This has the potential of a small problem as both should be backed up within a short amount of the other. If not then the worse case scenario is your database will point to files that don’t exist.
- Industry standard
- Must coordinate scheduling
There is some arguement to do both on occation especially if you have a seperate QA environment (recommended). The database backup are straightforward as long as you test recovering them to a seperate instance or the samme instance. Just make sure not to surprise users with a backup of yesterday’s information. I have included an example cronjob to backup media.
# cronjob 14 02 * * * /bin/bash /$BACKUP_HOME/bin/bricdump >/dev/null 2>&1
#Script #!/bin/sh # Declare what we need to start DATE=$(date +%Y%m%d) tar cfvz /$BACKUP_HOME/backups/bricmedia_$DATE.tgz /usr/local/bricolage/comp/data/media/
— Bric.ChrisHeiland – 21 Feb 2007