Backup Destination - limited hard drive space

[Ashen]

Wondering how people are managing this type of situation.

Backup Destination has allowable space of 600GB. Only one recovery set is kept at all times. Basically the BESR images are streamed to tape each night, so what is left is already off-site by the next morning.

First recovery point in a clean set = 350GB.

Subsequent 6 daily points are incremental and add a further 50GB to the set in total for the week.

End of the week, 400GB in total.

As the new week begins, a new recovery set is created, with the old set deleted. However, the 1st point in the replacement set is 350GB - there isn't enough space to write the 1st recovery point in the new set as it is 350GB.

The "Automatically optimise" storage option does optimise storage well, but not in this situation. The backup job is set to keep 1 recovery set only. So each week it begins a new recovery set and deletes the old. However it does not remove the  "Recovery Set" until after the job has completed. This is logical, you would always want this to occur so that the new "Recovery Set" is verified as being ok, before deleting the only recovery set you have.

However because we are streaming the recovery points each night off to tape, what resides in the backup destination is irrlevant.

This isn't so much of an issue if you have more than double the space that 2 recovery sets of this nature would need.

I could run a script to do this depending on the day/night of the week, but is there another way? Can you force BESR to:

Delete previous recovery set prior to creating a new recovery set.

That way, each week, the single recovery set will disappear, with the new set created from scratch on a drive with enough space. 

[David_F]

You would have to do something to manually netstop BESR services, wipe the destination space, delete the *.PQH on the client system, and then restart our service prior to its next schedule baseline image. 

[Ashen]

Hmm, there should be an option to force deletion of a recovery set prior to beginning the new set, be it the oldest or whatever.

Essentailly BESR is saying, sorry, you need enough space to cover one recovery set, plus the 1st recovery point in a new set. In alot of situations this will be quite a significant storage requirement.

I'm sure there are other reasons why you may want to do this.

When you say I'd have to manually netstop the services, why? Why not delete the physical files? Why is there a need to delete the PQH files? Are these pointers that indicate the system state at a particular point in time? If so, wouldn't not deleting them be ok if you are creating the 1st point in a new recovery set? 

[Jon_R]

The reasoning behind this is that the application wants to make sure that there are always as many valid recovery points available as specified by the user. This is because if there is an issue during a backup and the backup isn't created, if you only have one recovery point set saved and it deletes that prior to beginning the backup, you now have zero recovery points saved.

To answer your questions;

When you say I'd have to manually netstop the services, why?

The services need to be stopped so that you are given permission to delete the .pqh files.

Why not delete the physical files?

The backup files need to be deleted as well.

Why is there a need to delete the PQH files?

The .pqh files are history files that contain information about the backup files that the system should see at the backup destination.

[Ckidd_Ben]

I am also experiencing the same issue.  The "Automatically Optimize Storage" option is very misleading.

I'd have to upgrade to 1.5TB drives in order to comfortably store two restore points.  My 750GB eSATA drives only have room for one.

This needs to be an option.  Put a big warning next to it if you must.  I shouldn't have to write a script/batch to do something that the software should do.  Also, by me working around this, the recovery points won't be properly managed.

Thanks,

          Ben

[Jacob_A]

You can use the Send Feedback option under the Help menu to send in suggestions and requests for additional features.  These are used to help determine what features to add or alter.

[Ckidd_Ben]

Will do!

[Jacob_A]

Thank you for helping to improve the product, it is really appreciated.

[Oculus]

Similar Question.  Using BESR 8.0.  My backups are small, around 40 GB.  My portable backup drive is around 250GB so I can fit several backups on the same disk.  Selecting the 'automatic' option described, will BESR automatically delete the oldest backup and replace it with the most recent once the disk is full?

[aychekay]

Oculus,

It's probably best to post a separate question, if you haven't already, since your issue is different than the Original Poster's. 

In answer to your question, just tell BESR, in the backup job you created, to keep (4) Images. After BESR creates the 5th successful image it will delete the oldest one.

[aychekay]

Ashen and Ckidd_Ben,

I'd recommend using a script to delete your backup files before starting the next incremental backup set. I've started a blog where pre-command files as well as scripts are covered somewhat lightly. Check it out here.

If I'm understanding you right your script will need to be an "intelligent" script that doesn't delete anything until the day that BESR is supposed to start a new incremental recovery set. To date, I haven't developed any script that will do that.

I started a thread some time ago where users can share their feedback and suggestions here on the forum. You might consider dropping by there and adding your two bits.

https://forums.symantec.com/syment/board/message?board.id=besr_general&thread.id=507

[Ckidd_Ben]

Thanks aychekay.  I'll have to check it out.  Right now I'm using a simple batch file that has robocopy purge the older backup set.  It's not ideal because I'm backing up to my offline first, then having robocopy update my nearline backup.

(I swap external 750GB drives daily for my offline backup, but also have a 1.5TB external RAID array that is used as the nearline backup.)

Thanks,

         Ben