Backup copy folder double up

[Bignatenz]

First off, I'm the new guy in our team, so apologies in advance if i'm overlooking something obvious. I'm learning as I go

We have a series of backup copy tasks that replicate from our main datacentre to our secondary offsite one. earlier this week, one of the drives in the secondary DC was filling up, so we moved or of the backup copy folders to another drive on the same server with more free space. We changed the Target in Backup and Replication to point to the new drive (but not to the specific folder, it has since been discovered). In the subsequent incremental backups, it appears that Backup copy task has been using the new drive, but not the same folder. Instead it has created another folder using the same name, with _1 on the end of it, and is now copying and the backup files here.

Because it is now pointed to this new folder, the incremental backups in the original folder have not be included in the 'roll up' process (I believe this is what it's called, basically when the incremental .vib files are combined and condensed into a .vbk).

Is there are way I can reintroduce these files back into the folder which is now targeted by Backup and Replication, in a way that they will get 'rolled up' in to a .vbk file. I would like to think that copying them across to the "active' folder and letting Backup and Replication do its thing, is all I need to do. But i'm not sure if i'm overlooking something, possibly the fact that the newer .vib files are listed in their own .vbm file in the new folder, separate from the previous vbm in the old folder.

Any suggestions on cleaning up this situation would be much appreciated

[PTide]

Hi,

Do you see a .vbk file in the folder that has _1 on the end of its name?
Also, have you mapped your backup copy job to your original folder or just pointed it to a new drive?

Thank you.

[foggy]

I suspect that you just created another repository and pointed the job to it, without re-scanning it and mapping the job to existing backup files. Is that right?

[Bignatenz]

I suspect that you just created another repository and pointed the job to it, without re-scanning it and mapping the job to existing backup files. Is that right?

We didn't create a new repository, we moved the existing one from one drie to another on the same server, but yes we just pointed the job to it (the new drive, but not specifically the folder that we relocated, it turns out) in the "target" tab of the Backup Copy job in question. We did not re-scan or map the job to existing backup files. When the backups ran the next night, it had created a new folder (on the new drive) and saved the back up files there instead.

Now when we go into Backup and Replication > Backup Copy > Select the affected job > Edit > Target > Map Backup, there are two listings of the same name for the folder in question. Unfortunately, neither name has the _1, so we can't tell which is the new one.

[foggy]

We didn't create a new repository, we moved the existing one from one drie to another on the same server, but yes we just pointed the job to it (the new drive, but not specifically the folder that we relocated, it turns out) in the "target" tab of the Backup Copy job in question.

You cannot select the drive in the backup copy job, just repository. So you had to create a new repo pointing to the new drive, in any case.

We did not re-scan or map the job to existing backup files. When the backups ran the next night, it had created a new folder (on the new drive) and saved the back up files there instead.

So does the new folder contain VBK file as well?

[Bignatenz]

So does the new folder contain VBK file as well?

Yes the new folder does contain a VBK file, and VBM file that is being updated each day a Backup Copy runs

[alanbolte]

If you have a backup copy chain in one folder (VBK and VIBs), and another backup copy chain in another folder (VBK and VIBs), then regardless of how you got to that point, there is no way to combine those chains, you can only choose which chain the job is currently using. You should wait until either you no longer need the old restore point chain or you're low on disk space, then delete the old chain all at once.

[Bignatenz]

Okay, thanks for the help. Further to this issue, the folder with the current backup chain has _1 on the end of the folder name. Once we delete the old backup chain and the folder it was in, can we remove the _1 from the name of the current chains folder without causing any issue? Just for the sake of tidiness?

[veremin]

Yes, you can do that. But just to be on the safe side I'd explicitly map the job to the chain present in the renamed folder afterwards. Thanks.