Browse KB by category:
Go to KB #:
Using Multiple Stage Destinations with BRU Server 2.x
Using Multiple Stage Destinations with BRU Server 2.x
By default, BRU Server only supports a single Stage destination. You can utilize multiple Stage destinations in BRU Server 2.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.
Please make sure that when creating additional users (all lower case) and the symlinks (also all lower case) that correspond to the user that the name is unique. You should not create a username that matches a username that has been created using the BRU Server Agent
for client side backups.
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.
Important: The names of the symlinks inside of the BRU Server stage path must be all lower case. BRU Server does not create users with capitol letters in any way. If you use a capitol letter in any part of the symbolic link, the contents of that folder will be deleted the next time the BRU Server Housekeeping process runs.
sudo mkdir /Volumes/Firewire\ Drive\ 1/Backups
sudo ln -s /Volumes/Firewire\ Drive\ 1/Backups/ /Volumes/RAID\ 1/Backups/daily1
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 2.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:
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:
(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 2.x is to create a symlink to the firewire drive ("/Volumes/Firewire 1/Incremental" in this case):
sudo /usr/local/bru-server/server --kill
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).
Effective in version BRU Server 2.0.1, logging in as the desired user to assign the backup job to that user is no longer required. When creating a backup job with the intent to have the job be assigned to another user for the purposes of backing up to multiple disks, specify the job owner on the Job Settings window as shown below:
If you do this using the command line 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.cmd tool or the Command Console located in the BRU Server Console (File -> Command Console), change the owner of the upstage job to the "special" user:
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.