Backup to disk to removable disk

[Rick_DeBay]

In order to work around the concurrent job restrictions with removable backup-to-disk folders, I'm thinking of backing up to a local disk and then moving the files to the removable drive.
What do I need to do to implement this?  BE needs to be able to restore from the removable drive, and the fixed drive should be empty after the job(s) complete successfully.

[lhawthorne]

Use the 'Post command' capabilities to launch a batch file that will delete the files from the staging area.

[Ken_Putnam]

1)  In order to restore from the removeable drive, you have to execute a DUPLICATE job from with BackupExec

2) cfunderb's suggestion about the POST command should work.  Set it to run only on successful completion of the DUPE job 

[teiva-boy]

Why not just set the overwrite period to 1 hour.  It doesnt reclaim the space per say, but will over write the existing disk images as needed.

[Rick_DeBay]

I know this can be done with the duplicate template, but I can't see how to remove the backup files from the staging area.  This space needs to be reclaimed for use outside the backup window.

I also need to make sure that the duplicate has overwrite restrictions of weeks, but the original at the staging location can't have such a long life otherwise the disk will fill quickly.

[Colin_Weaver]

Ok a lot of comments coming up

1) I have not tested it yet but BE 2010 R2 has an enhancment against using USB drives as Backup to Disk locations in that if the drive letter changes because the disk is unplugged BE should correct the drive letter and still see if as a B2D location . I am not 100% sure if you should now use a USB disk as a Removable backup to disk folder or a standard one with this enhancment (hence needs a bit of testing.) I suspect this may still need a device pool for the devices on the USB disks.

2) In older versions of Backup Exec Removable Backup to disk folders were ONLY ever intended ot be used for devcies that remain online, on the same letter that just have removable platters or cartidges (such as CD-RW, DVD-RW and certain cartidge based HDD systems.) USB devices were not in the design of 'removable backup to disk' targets

3) Some customers have got Removabe Backup to disk on a USB disk to work by creating a uinique Rmeovable B2D for each drive, add these R-B2D decices into a Devcie poo, target teh jobs to teh device poll and set the last job of each day to ejecet the media. Note this might have issues with drive letters.

4) Copying or flat file backing up the BKF files or IMG folders is NOT recommended - unless you shut down the Backup Exec services and copy the database at the same time. Followed by having a restore process where you put the old backup exec database back to match the disk content you restore. if you copy old BKF or IMG folders without restoring the timematched database you will introduce inconsistencies that could mean you are unable to restore or even catalog from the media - and obviously if you restore an old database you have to protect  yoru current database first as otherwise you wil lose the new information. As such you shoudl alwsays Dupliacet data from backup to disk targets.

5) BKF files will just get overwriteen by the noormal media overwrite rules so as longas you set your overerite procetion correctly there shoudl be no need to manually delete them.

6) IMG folder deletion should be covered by the backup jobs looking for an overwritable IMG folder at the start of every unique GRT set (an Exchange information store is one set) so again get your overwrite protection rigjht and you should not have disk space issues - however a colleague has been investigating an issue and it is possible that for IMG folders to be correctly reclaimed that the Backup job will have to start as an overwrite not as an append. If this is corrcet then it is a possible defect in the process for deleting IMG folders.

[Rick_DeBay]

Is deleting the files from a batch file safe?  The documentation states that the GUI must be used to move the media to the retired set, then delete it from the retired set, then you can delete it from the disk.

[Ailbe]

Hi Collin, thank you for the update to this.  I do have a question though.  You say that
"4) Copying or flat file backing up the BKF files or IMG folders is NOT recommended - unless you shut down the Backup Exec services and copy the database at the same time"

I have a policy with 3 templates.  1 for the weekly full backup going to disk with a retention of 6 days, 1 for the daily incremental backup going to disk with a retention of 6 days, and a template that duplicates the first 2 templates to tape on Sunday.

Can you recommend a way to do this without having to backup the BE databases?  My situation is similar but different from Ricks.  We have a client mandated need to keep the backups for 1 month, but only have the disk space to keep a little more than 1 weeks worth of data.  So the solution we were going to present was keep the last weeks backups on disk and then on Sundays duplicate the backups to a tape.  This way if anything happened within the week a restore was easily available from disk, if a restore was needed from beyond a week we would grab it from the tape.  From what you are saying here, it doesn't quite work that way, or is quite a bit more complicated...  Or is doing this through the duplication process better somehow than "copying or flat file backing up the BKF files"

[Rick_DeBay]

The post command is not available for a duplicate job.

[Rick_DeBay]

The duplicate process should allow BE to keep track of the duplicates.  If you copy on your own, it doesn't know that your tape holds another copy.