No matter what size your network, you can support it with easy to manage centralized, enterprise-grade tape, disk, or cloud data backup and recovery services with complete regulatory compliance. All major OS platforms – macOS, Windows, Linux, Unix – are GUI supported as well as your existing hardware or cloud storage services.
No limits. No limitations.
Because backup and archiving is not a one-size fits all solution, the BRU products are individually designed to meet all needs. Out of the box, ArGest® BRU Server™ v2.0.7 software supports unlimited data amounts for backup with no additional fees in single BRU archives up to 16 exabytes each. The BRU™ engine natively powers our macOS backup software solutions, our Linux backup software solutions, as well as providing the reliability, speed, and power behind our tape hardware and disk storage solutions. FreeBSD 11 and 12 are supported both as clients of macOS or Linux BRU Server installations, and also as a BRU Server Server host for disk only operations.
ArGest® BRU Server™ v2.0.7 software supports users’ existing hardware or cloud storage services, and is also available bundled with tape and disk RAID hardware with the TOLIS Group BRU Server™ standalone LTO, automation/library units, or expandable disk storage solutions. ArGest® BRU Server™ is also available pre-configured on our bruAPP™ personal cloud-based backup appliance. Our hardware/software bundles provide a single source of support help and warranty services for all items related to the backup/archiving task. Automated archival solutions for medical, law enforcement, government, and other business types who’s needs require specialized archive services to access data from network storage locations to a central network archive and restore archived data back to the network storage locations are available as well.
ArGest® BRU Server™ v2.0.7 never assumes that the data you write to disk or tape is data that is actually recoverable and provides the assurance that the data you think you have backed up can actually be restored. BRU™’s error recovery algorithms used when writing to tape provide reliability mechanisms unlike any other backup product on the market. BRU™ can even restore data from the readable portions of a physically damaged tape.
These features are discussed in depth in our white papers titled: The BRU Advantage and Reliable Verification with BRU.
ArGest Server: Network Backup and Archival for a single server or a complete enterprise:
BRU Server’s “server component” runs natively on macOS. Linux, Solaris, and FreeBSD.
The Agent component is installed on all machines that are to be backed up by BRU Server. Those machines become clients of the BRU Server server system (including that machine itself if it to be backed up). The BRU Server Server component with BRU Server Agents for all Unix-based (including macOS) and Windows systems protects the critical information residing across your client/server based network.
The BRU Server Graphical “console component” can be installed on any number of systems to manage BRU Server’s operation. The proven reliability of BRU technology coupled with the proven reliability of a Unix-based operating system creates a backup system of unsurpassed uptime and availability to archived data.
BRU Server supports all forms of archive storage including disk, tape, virtual tape libraries, NAS and SAN devices. The built-in architecture supports D2D, D2T, and D2D2T without the requirement of expensive add on licenses.
ArGest® BRU Server™ System Examples:
Example Workflow
We are frequently asked about our recommend workflow for BRU Server™. While there are many workflows that BRU Server™ can manage depending on your particular needs, this is an example of one used by TOLIS Group for our internal corporate backups.
The purpose of this workflow is to create jobs that properly mitigate a disaster should it happen.
We use an ArGest® LTO-6 TGL2240 internally for our business backups. Each full backup takes 2 tapes. We also have 40TB of RAID 5 disk for Staged D2D in our bruAPP™ Backup Appliance.
In the BRU Server™ environment, we have the destinations in our ArGest® TGL2240 set up as follows:
Week A – Slots 1-2
Week B – Slots 3-4
Week C – Slots 5-6
Week D – Slots 7-8
Monthly Offsite – Slots 13-14
Quarterly Offsite – Slots 15-16
As sub-jobs and destinations, the engineering data all fits on a single LTO-6 tape, so we have
Engineering A – Slot 9
Engineering B – Slot 10
Engineering C – Slot 11
Engineering D – Slot 12
Engineering Offsite – Slot 17
Engineering Quarterly – Slot 18
Slots 19-23 are for emergency jobs – both backup and restore – while slot 24 is the cleaning cartridge
This layout means that the tapes in the left magazine are pretty static while the tapes in the right magazine are the ones being swapped in and out.
Our backup rotations work this way:
Each Friday night, the full job for all client systems run to a Week destination on a 4 week rotation schedule.
The first Saturday of each month, a separate full job for all client systems run on a monthly schedule with each set being taken offsite to one of the employees’ houses where it is rotated back in every 6th month.
The last Sunday of each quarter, a separate full job for all clients is run to the Quarterly Offsite destination and then taken to our bank’s safe deposit box and never brought back in.
Every day at 12:30 and 18:30, an incremental job of all pertinent systems is run to the server’s Disk Stage and that environment is set to a 91 day max stage age – meaning that the system automatically removes any incremental jobs from the disk as soon as they are 92 days old keeping the disk stage automatically groomed.
The engineering schedules are similar, except that the quarterlies are stored by our law firm for software code escrow for customers that have a code escrow agreement with us.
This process keeps 4 weeks of full archives in-house, 6 months of full archives offsite, but rotating back in for overwriting, and a set of legal full jobs for business purposes that are never overwritten. The incremental archives are not needed after a new full job, but we keep them around for 3 months for “oops” coverage.
Again, there are many workflows that we are able to discuss and support, this is simply one example.
Excluding Specific Files or File Types From Backup?
Excluding Specific Files or File Types From Backup
In addition to explicitly specifying excluded paths in the backup job definition, each client system may have a list of parameters that will cause the backup operation to exclude specific files, directories, or file types for any backup. This file is the ‘bruxpat’ (BRU eXclusions PATtern) file. It is placed within the actual agent install directory on each client system.
These directories are –
macOS and Unix variants
“/usr/local/bru-server”
On Windows Systems
“C:\Program Files (x86)\TOLIS Group\BRU Server Agent Configuration\“
There are sample files included within the directories that may be viewed for further details. This is a plain text file that contains a list of patterns to match for exclusion. While the patterns my be defined as either standard shell patterns (xs) or regular expressions (xr), most users will find the shell patterns easier to work with. A simple exclusion of all MP3, WMA, and AAC files would be:
To accomplish this with a regular expression exclude pattern, you could use:
xr */*.[mM][PpMm4][3aAp]
This says in any directory, match any file that has an extension with a first character m or M, a second character P, p, M, m, or 4, and a last character of 3, a, A, or p.
Note: If you receive a message line in your logs that reads:
bru: [W140] error – unable to read include/exclude pattern file: “/usr/local/bru-server/bruxpat”
Archive may contain unexpected files.
You should create the missing “bruxpat” file on the client system being backed up. The path to where the file is expected to be found is listed in the message. If you are not actively adding files for exclusion, you may simply “touch” the file to eliminate this message.
sudo touch /usr/local/bru-server/bruxpat
sudo chmod 777 /usr/local/bru-server/bruxpat
Executing Tasks Before or After a BRU Server Job Run
If you have a task that should be performed before or after the BRU Server job is executed, there is a mechanism provided for both agents and the server. Such tasks include stopping and restarting a mail server, exporting a database to a flat file, warning users that a backup is about to occur, and many more. The files may be created using any programming of scripting language supported by your system including shell, python, perl, Applescript, or even compiled C/C++. The only requirement is that the resulting file be executable and return a zero for success or non-zero for any error condition.
On your client systems, add executable files named pre and post to the agent installation folder –
“/usr/local/bru-server” on all macOS and Unix variants, and as pre.bat or pre.cmd, and post.bat or post.cmd in
“C:\Program Files (x86)\BRU Server Agent Configuration\” on Windows systems.
Additionally, there is a master pre and post capability on the server system. The file should be placed into the server application directory – “/usr/local/bru-server/” – and be named backup.pre and backup.post. The server sequences will be executed before any client backup operation is begun and after ALL client backup operations have completed. The same rules apply for creating the server-specific jobs as for the client system pre and post sequences.If you have a task that should be performed before or after the BRU Server job is executed, there is a mechanism provided for both agents and the server. Such tasks include stopping and restarting a mail server, exporting a database to a flat file, warning users that a backup is about to occur, and many more. The files may be created using any programming of scripting language supported by your system including shell, python, perl, Applescript, or even compiled C/C++. The only requirement is that the resulting file be executable and return a zero for success or non-zero for any error condition.
On your client systems, add executable files named pre and post to the agent installation folder –
“/usr/local/bru-server” on all macOS and Unix variants, and as pre.bat or pre.cmd, and post.bat or post.cmd in
“C:\Program Files (x86)\BRU Server Agent Configuration\” on Windows systems.
Additionally, there is a master pre and post capability on the server system. The file should be placed into the server application directory – “/usr/local/bru-server/” – and be named backup.pre and backup.post. The server sequences will be executed before any client backup operation is begun and after ALL client backup operations have completed. The same rules apply for creating the server-specific jobs as for the client system pre and post sequences.