KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Email   Bookmark

How do I utilize multi-staging in BRU Server v1.x?

Views: 16041
Posted: 02 Oct, 2007

Using Multiple Stage Destinations with BRU Server 1.x

By default, BRU Server only supports a single Stage destination. You can utilize multiple Stage destinations in BRU Server 1.x through creative use of additional user accounts. Because each defined BRU Server user for a given server gets their own folder beneath the Stage path folder, it is possible to provide for multiple Stage destinations by using multiple users and symbolic links† (symlinks). Support of multiple stage destinations will be included in a future version.

While this process does require a basic understanding of using the command line, the process is relatively straight forward.

Given a Stage path of “/Volumes/RAID 1/Backups/”, BRU Server automatically creates the default “admin” user folder when it is run. By creating the additional user folders as symbolic links to alternate locations, you can use additional disk volumes or folders to store additional disk archives.

With our Stage path as defined above and the desire to use 2 additional Firewire drives as alternate Stage locations, we can create two additional user accounts - Daily1 and Daily2. These BRU Server users’ archives are to be written into the Stage hierarchy under folders Daily1 and Daily2 respectively. To configure this, start by creating symbolic links between the BRU Server Stage folder and the Firewire hard drives. Note that the Firewire hard drives MUST maintain their mount naming and remain mounted for this to work as expected:

sudo mkdir /Volumes/Firewire\ Drive\ 1/Backups
sudo mkdir /Volumes/Firewire\ Drive\ 2/Backups

sudo ln -s /Volumes/Firewire\ Drive\ 1/Backups/ /Volumes/RAID\ 1/Backups/Daily1
sudo ln -s /Volumes/Firewire\ Drive\ 2/Backups/ /Volumes/RAID\ 1/Backups/Daily2

At this point, the primary Stage folder will have the subfolders that will contain the archives created by jobs owned by the users Daily1 and Daily2. Although these folders are actually symbolic links, the BRU Server disk writing process will follow the link when writing the actual archives and the physical data will be written to the assigned folders on the two Firewire drives.

The next step is to create the users within BRU Server. Since this particular example is aimed at disk to disk backups only, you can accept the default settings for Max Stage Age and Disk Quota when creating the users “Daily1” and “Daily2”.

The final step is to create your backup jobs, assigning the ownership of the appropriate job to the appropriate user depending on where you want the archive to be written. It is the ownership of the job that will define which of the symlinked folders will be used for each job’s archive.

Use a Combination of Disk and UpStaging To Tape

To involve multiple Stage paths in 1.x with some archives staying on the Stage disk and others being UpStaged to tape, we modify the information above as follows:

By setting up 3 additional users, you can accomplish this mechanism by assigning differing "Max Stage Age" values for each of the users.  This would allow you to run Full backups that are saved for 120 days and Incremental backups that age out after 30 days and don't get upstaged, while special jobs can then be run and are UpStaged to tape on a defined schedule.

The first step is to create three additional users (in addition to the admin account): Full, Incremental, and Special:

  • Set Full's Max Stage Age to 120
  • Set Incremental's Max Stage Age to 31
  • You can leave Special's Max Stage Age alone as we'll be upstaging those archives.

The Full and Special users’ archives go to the Xserve RAID, while the Incremental user’s archives go to a G-Technology 1TB Firewire drive (see below)

Within BRU Server, set the normal Stage path to:

/Volumes/RAID\ 1/Backups

(assuming the Xserve RAID is mounted as "RAID 1").  Under that path, you would end up with the four user folders: admin (the default user), Full, Incremental, and Special.  However, we want the Incremental to go to the Firewire Drive, so we'll need to do some manual work before we restart the BRU Server server daemon and the jobs running.  As mentioned above, the solution to using multiple volumes/paths under 1.x is to create a symlink to the firewire drive ("/Volumes/Firewire 1/Incremental" in this case):

sudo /usr/local/bru-server/server --kill
sudo ln -s /Volumes/Firewire\ 1/Incremental /Volumes/RAID\ 1/Backups/Incremental
sudo /usr/local/bru-server/server

BRU Server will automatically create the admin, Full, and Special folders when it's run for the first time, but skip creating the Incremental folder since the folder already exists (the symlink created above).

There is one limitation in the UpStage process that will again require a bit of behind-the-scenes manipulation - the assignment of the UpStage job to ONLY move the archives that belong to the "Special" user.  You do this one of two ways:

  1. By logging into the console as the user "Special" instead of “admin” when creating the jobs
  2. By using the bru-server.console tool to change the owner of the UpStage jobs. 

If you do this using the second method, here’s an example of the steps. Given backup jobs named "My Spec 1", "My Spec 2", and "My Spec 3", login to the bru-server.console tool and change the owner to "Special":

setc -m backup "My Spec 1" owner "Special"

Do that for each of the backup jobs.

Next, create the UpStage job for the Special jobs as the "admin" user. For this example, name it "Weekly Upstage".  Once again from the bru-server.console tool, change the owner of the upstage job to the "Special" user:

setc -m upstage "Weekly Upstage" user "Special"

This change to the default UpStage job settings, where no user is specified, changes the UpStage process to ONLY UpStage the archives created by the specified user account ("Special" in this example).

†A symbolic link is a special type of Unix file which refers to another file by its pathname. A symbolic link is created with the "ln" (link) command: ln -s OLDNAME NEWNAME where OLDNAME is the target of the link (usually a pathname) and NEWNAME is the pathname of the link itself. In contrast with hard links, there are no restrictions on where a symbolic link can point.

Others in this Category
document What are the firewall settings to allow BRU Server to communicate through a firewall?
document Is BRU Server 1.2.0 Supported on Snow Leopard?

Powered by KnowledgebasePublisher
Page Load Time: 0.035377 seconds / 35.377 milliseconds.
Page File Size: 27389 bytes.