Probably the #1 question when people consider what they need to do

to implement a Reload server is, "How much disk space do I need?"

There are simple forumlas to use and more complex ones.

Here's the simple formula 2.5 Times the size of the post office for every week you want to keep on the Reload server.

So if you have a 100 Gigabyte post office, and you want to keep around two weeks of backups, then you generally want about 500 Gigabytes of space on the Reload server. However, there are some other things to consider, which is why I encourage you to read on.

Let me try and explain how the disk space is used first, then we'll work on formulas.

Let's take an example scenario. A GroupWise post office with 100 Gigs taken on the disk. GroupWise has an AWESOME message store design, and Reload leverages GroupWise's superior design to make backups extremely small.

All GroupWise post offices follow roughly the same percentages explained here.

A 100 Gig post office is 10% dynamic data and 90% static data. The

dynamic data is kept in the OFUSER and OFMSG directories off of the

post office directory. The static data is kept in the OFFILES

directory off of the post office directory. Files in the OFFILES

directory are commonly referred to as BLOBS (Binary Large OBjects)

Reload refers to them as Databases and BLOBS respectively.

The very first Reload backup copies down all the data from a

GroupWise post office to the Reload server. The static data is kept

in a "Master BLOBS" directory for the Reload profile. The dynamic

data is kept in a directory that corresponds to the day that the

backup was performed. Backup sets are selectable from the Reload

Administration menu with names that correlate the directory that

the backup is kept in. For example: [WEDFEB13].

If you were to browse to the webfeb13 directory in a file manager,

you would see what looks like a GroupWise post office. There's the

WPHOST.DB and the NGWUGARD.DB, the OFVIEWS etc. There is an OFUSER

and OFMSG directory, and the OFFILES directory. However the OFFILES

directory is actually a "link" to the Master BLOBs directory. The

Linux platform is what makes this linking mechanism available. The

actual term in Linux for this functionality is a "symbolic link".

However you don't need to know how these links work to make Reload

work, it just all happens, but it's this linking that allows Reload

to provide such tremendous disk space efficiency.

The very first Reload backup that you perform is 100% of the size

of the post office. So for a 100 Gig post office, 100 Gig is take

in disk space on the Reload server.

[+100 Gig - First Backup]

The next night however, a backup takes 12% of the size of the post

office. Here's how it's done:

1. The databases at the root of the post office and in the OFUSER

and OFMSG directories are backed up in their entirety.

2. The Additional BLOBS that have been created on the live post

office and are in the OFFILES directory, are copied to the Master

BLOBS location on the Reload server. On the average GroupWise post

office the daily growth in the OFFILES directory represents about

2% of the total size of the post office.

So Reload has actually done what would commonly be referred to as

an "Incemental Backup". Namely Reload backed up data that changed,

and new data.

Reload then does this:

- Makes the DAY-DATE directory spoken of earlier

- Copies the GroupWise databases to their appropriate locations

such as OFUSER, OFMSG etc.

- Links the OFFILES directory to the Master BLOBS directory

So the Incremental Backup is now just as effective and usable as a

full backup set.

The reason for this is that BLOBS, which represent 90% of the

GroupWise Message Store never change from day-to-day. All that

Reload needs to do is copy down the new BLOBS that get created, and

link to the existing BLOBS.

[+12 Gig - Daily Backups]

Each night's backup is going to be exactly the same. So at the end

of 6 days, the Reload server now has effectly 6 Full Backups of the

100 Gig post office, and the disk space on the Reload server that

is allocated to backup that post office is approximately 162 Gig

[=162 Gig - 6 Days of Backups]

Generally every week, you want Reload to create a Portable Backup.

The Portable Backup in Reload is somewhat equivalent to a Full

Backup, however the comparison isn't perfect. The Portable Backup

provides the following features:

1. A Portable Backup can be pushed into a Tape Archive (.tar) file.

2. Portable Backups remove the BLOBS on the Reload server that are

no longer being used on the live server.

Most notably thought, a Reload Portable backup is dissimilar from a

traditional Full Backup in that a Reload Portable Backup does not

pull any data from the live server. Reload simply copies data from

one location on the Reload server to another location. So with

Reload, you no longer have to consider a big window to allocate for

the full backup of your post office. This never happens with

Reload, outside of the first Reload backup.

Reload Portable Backups typically contain within them 6 days, and

an entire copy of the Master BLOBS directory replicated into the

Portable Backup. So now, once a Portable Backup is complete, the

Master BLOBS directory has been replicated twice.

Here's what is being taken on the Reload server now:

+90 Gig for the Master BLOBS directory
+162 Gig for the 6 Days of Backups held in a Portable Backup
=252 Gig

Let's say though, that you want Reload to also create Tape Archive

files of the Portable Backups. You should add an additional 184 Gig

to the equation.

+90 Gig for the Master BLOBS directory
+162 Gig for the 6 Days of Backups held in a Portable Backup
+162 Gig for the *.tar file of the Portable Backup
=414

In Reload, you can define how many Portable Backups you want to

keep on the Reload server. Most customers want to have about two

(2) Portable Backups. Here's the disk space you should allocate for

this scenario:

+90 Gig for the Master BLOBS directory
+162 Gig for the 6 Days of Backups held in a Portable Backup
+162 Gig for the 6 Days of Backups held in a Portable Backup
+72 Gig for the next 6 Days before another Portable Backup

=486 Gig

Technically with 486 Gigabytes Reload provides you with at least 12

days of backups and up to 18 days of backups. Just to make a

contrast to snapshot or full backup to disk technlogies, if you

were using one of those technologies you would need 1.2 Terabytes

of disk space to get this same functionality.

Let's say you want Reload to also create the Tape Archive files,

and you tell Reload to delete old Tape Archive files. Then add an

additional 162 Gig.

+90 Gig for the Master BLOBS directory
+162 Gig for the 7 Days of Backups held in a Portable Backup
+162 Gig for the 7 Days of Backups held in a Portable Backup
+72 Gig for the next 7 Days before another Portable Backup
+162 Gig for Reload to create Tape Archives

=648 Gig

There are some other factors to take into account to size things

appropriately. Reload has a disk space threshold check, that is set

at 90% by default. To maintain this feature, you want to allocate

an additional 10% of disk space. I think it would also be prudent

to add an additional 30% for growth. Even with other Hot Backup

solutions you would want to consider such things. So in total, you

may want to consider an additional 260 Gigabytes. In total then:

908 Gigabytes

Now if this number seems just too big, let's tell you how you can tweak it a bit.

- You can shave off the Tape Archive Feature
- You can run the Portable Backup routine every two weeks rather than every week

There are some other things to consider when determining disk space. Do you have Document Management Libraries at the post office? Do you intend to have Reload backup up the the Libraries? If so that changes the amount of disk space needed.