Jump to content
Sign in to follow this  
awnews

RMS Proactive replication and grouping

Recommended Posts

Using RMS6.5, 30-day trial.

 

As I'm setting up the Proactive option on clients, I'm setting each client up one by one and each backup (proactive) backup set one by one. This results in a proactive backup "script" per client and a single File backup per client. And yes, I know that I can copy scripts to save a bit of time, but I still have to select clients and set up File backup dest. per script. If I don't break things into separate scripts, I would end up with multiple clients backed up to single destination file.

 

It seems like it would be nice if there were a way to cluster/group Proactive clients into sets so that the same rules could be applied to each *but* RMS would algorithmically generate the backup destination files. So if I'm backing up clients PC1, PC2 and PC2 in a single proactive script, I would like RMS to generate separate output files PC1.rbf, PC2.rbf and PC3.rbf (i.e. a file per client) in a selected backup directory.

Share this post


Link to post
Share on other sites

> May I ask what's the reason behind having one backup set per user?

 

A few things I can think of (and I'm open to counter arguments)

 

1) Size. I'm backing up *everything* on each user's system. This has been averaging about 2GB per system. Assuming that I logically group 20 users per group based on logical needs at the school (100+ PCs to back up), that would be 40GB files+incrementals. Big, and if a backup files becomes corrupted I lose the whole backup. I'm free to group things other ways (e.g. 5 users per group) but RMS shouldn't force that on me. Also, I can copy "small" (<4.7GB) files to DVD-R if I elect to take specific ones off site (and my Lite-On DVDRW/CDRW is not supported by Dantz).

 

2) Recovery. I would think it would be a lot easier when recovering files to go to a specific file backup for a specific user and search for files, snapshots, etc. Is the RMS UI to a multi-client backup such that each client's backup is separate and easy to get at in a multi-client backup?

Share this post


Link to post
Share on other sites

Hi

 

When you start a restore it will show you the client name as well as the volume name for each snapshot. Even with a large number of users it is pretty easy to pick out the drive you want to restore.

 

It sounds like you are using a "disk" backup set? If so you should not need to worry about corruption too much. With a disk backup set the data is stored in 600 MB chunks. Even if one of those files was lost/corrupt/damaged somehow it would not affect the rest of the backup. In my experience, only media failure or corruption will damage Retrospects backup data. It doesn't break on its own.

 

Nate

Share this post


Link to post
Share on other sites

Actually I'm using File backup. I probably should experiment with Disk, but the last time I did so I tried it it behaved "oddly" so I gave up on it and went back to File. BTW, my dest. backup drives are always formatted as NTFS, which is fairly tolerant of and resistant to disk problems.

 

On the Disk backup, if I have a ten file backup set (e.g. Disk1, Disk2, Disk3... Disk10), which is really a single backup broken into ten pieces, what happens if one of those Disk files is deleted or corrupted? Is Retrospect smart enough to say "oh well, we've lost the files in that Disk file but I can recover the others" or is the *entire* set rendered useless?

 

And, I guess a fair question is to ask the same thing for a File backup set. If part of a File backup set becomes corrupted, will Retro "work around" (skip past, resync after corruption, etc.) the problem to restore whatever files are still OK, or does it take an all-or-nothing position--"file is corrupted, oh well, all the files are not recoverable?"

Share this post


Link to post
Share on other sites

Hi

 

Disk backup sets keep the backup data in sequentially numbered files within a folder on a disk. each one of those files is its own separate piece of the backup. They do not depend on each other to function although you will need all of them to do the full restore.

 

In other words, if some of those files go bad somehow, Retrospect will restore what it can from the other remaining files.

 

This is much more fault tolerant than "file" backup sets that keep everything in one giant file. I have worked on a couple of cases where a portion of the hard disc containing a file backup set became corrupt. To get the data we had to manually work around the corrupt portion of the backup file by choosing small pieces of data and restoring them a little bit at a time. Depending on the severity of the corruption you can get some of the data back but it is a pain for sure.

 

To be clear - I have not seen a file backup set fail due to corruption in Retrospect. It only happens when the media goes funny.

 

Nate

Share this post


Link to post
Share on other sites

I can confirm that when Retrospect 6.0 runs out of disk space the backup job will freeze and I get either catalog out of sync or corrupted backup set sometines. File set corruption also happened once when Retrospect froze and I had to "end task" it.

 

I have since upgraded to 6.5 and am using disk sets. Since the upgrade I did not encounter such problems as of yet (I did not run out of disk space, though).

 

computer.gif

Mikee

Share this post


Link to post
Share on other sites

Hi

 

Was whis is with a "File" backup sets or a "disk" backup set?

 

The problem with file sets is they are just plain files. Like other files, it is hard to predict what state that file will be in if the disk gets full and a write operation is interupted.

If the disk gets full when writing to the set, the catalog updates can't be merged back into the set so the catalog can get damaged. (This is true in 6.5 too) Freeing up space on the disk somewhere or copying the backup file to anotherlarger disk should allow you to do a catalog rebuild and access the data again.

 

Agreed Retrospect could handle this more gracefully, But with "File" sets all Retrospect knows about is the backup file itself. It doesn't track any information about the volume where the file is stored.

 

Nate

 

 

 

 

Share this post


Link to post
Share on other sites

Hi Nate.

 

Yeah, I had problems with File set in the past.

 

The more Retrospect is aware of the environment (at least keeping track of disk space to exit gracefully when it's low) the more reliable it can be.

 

computer.gif

Mikee

Share this post


Link to post
Share on other sites

I look another look at doing a Disk backup rather than a File backup and remembered one of the reasons I gave up on Disk.

 

When I do a File backup, the program asks me where (computer\drive\folder...) I want to save the file. So I can save to any directory on any drive I can access (local, over a network, etc.).

 

When I do a Disk backup, the program just shows me list of available drives (root drive only), with no option to save to a specific folder or sub-volume. This is pretty useless when trying if the program is going to just save files "somewhere" at the root of the disk (where it may not have write permissions, where *I* don't want files saved, etc.).

 

All I want Disk backup to do is save files to the a specified place (computer\drive\folder...) *but* break them up into the 650MB chunks.

Share this post


Link to post
Share on other sites

Yeah, it would be nice to be able to save the Disk set in a choosen folder. However, thinking about it more there might be a workaround: Under W2k and up you can share a local folder and than map to it. So you could pick the folder you want it in, share it, map a drive to it than let RS save the Disk set to. I never did it myself so do let us know if it works, if you try it. It seems like it would even be possible to pick a share directly (w/o the need to map a drive) when creating a Disk set...

 

computer.gif

Mikee

Share this post


Link to post
Share on other sites

Thanks for the mountpoint/share idea. I'll take a look at it. This could get kind of messy if I have a dozen folders, sub-folder, etc. that I want to save to (setup, flattening of the hierarchy, etc.).

 

I've actually been puzzled as to why there's a difference between a File backup and a Disk backup. It *seems* like it should be possible to have a single unified I/F & type, with file(s) saved to a specified location. A user could then elect to save to a single file (current File backup) or break up the file into N max-size (e.g. 650MB) files (current Disk backup). The catalog file can be saved as a separate file in the same directory or as part of one of the backup files.

 

The spanning feature of Disk (again, should be collapsed into a single File/Disk type) also needs some simplification and clarification. As an example, I have a 250G HD in a PC to be used for backup. I want to throw in another 250G to allow for additional backup space without the need to move files around, re-set Destination options in scripts, etc. I would *like* to specify the "overflow" location/algorithm by stating that backups can "span" from \\Computer1\DriveM\FolderTopM\FolderBotM --> \\Computer1\DriveN\FolderTopN\FolderBotN --> \\Computer2\DriveR\FolderTopR\FolderBotR etc. as additional storage is needed and more Disk1.rbf, Disk2.rpf files are generated. Any computer, any media, any folder, etc.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×