Full Veeam Backup-Copy run after remap?

[Tom_LeFx]

Hi,

I had to change the IP/Hostname of my primary onsite repo - the old way was not good, because it mapped to a fixed IP-address, which we had to change.
To do so, I followed this thread:

https://community.veeam.com/discussion- ... itory-3038

Things went well - I added the new old repo, decrypted the backups and remapped the jobs.

What happened after is, what confuses me:

The backup-copy-jobs, that are attached to all 3 of the primary jobs in "immediate mode" started running and said, that there were "RPO violations" and backups had not been copied for weeks - so they started running again and as it seems, they do run a full copy now again.
Why is that? I simply remapped the existing jobs and I would have hoped, that Veeam is able to figure that out?
Did I do something wrong?

Repos are Linux XFS repos, backup copy is "hardened", both have immutability enabled for 7 Restorepoints.

[Mildur]

Hi Tom

That doesn't sound right. Mapping a Job to an existing backup chain won't start Active Fulls backups.
An active Full backup may be started if the source machines ID has changed. Which wasn't the case in this situation.

I believe it's worth to check the logs. Can you open a case with our customer support and let me know the case number?
Logs will tell why the old backups weren't recognized and an active full backup was started.

Thank you,
Fabian

[Tom_LeFx]

Hi,

just make sure:
There weren't any active full backups run. The remapped backups just continued to work.
What happened was the Backup-Copy-Jobs started running again - it iterates over every backup to synchronize that again.
After it finished with the smaller VMs, I can now see, that the backup copy has more backups than the original job, but the total backup size seems equal (so dedup worked )

The current main VM is still running.

I will try to open a support case - but I am only on community

[Mildur]

Hi Tom

That sound like you are on V12 and have upgraded your backup chains to the new format.
If you had per-job backup chains or periodic copy jobs before, we will synthesize new backups per machine when you map the jobs to a backup chain.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

If that‘s the case, a support case is not required.

Best,
Fabian

[Tom_LeFx]

I am on v12,yes - but I changed the primary backup location just recently and updated to v12 a few weeks ago already.
I am running the backups as "one-job-per-VM" and the backup-copy-jobs are on "immediate mode" and also as "Secondary Location" per job.

I am just wondering, why remapping made it go over all the copy-data - nothing changed for that :-/

I created a support case - ID #06027140
The logs are huge - mainly the one of the big VM job, that seems to be mostly flooded with remarks, that something could not open the backup (because - well - it is still running the copy job for 10 TB of data) :-/

If the behavior is really expected, I need to cancel the whole copy operation and bring my offsite-repo back into the office, so it can work through all that data at LAN-speed and not via WAN-interface

[Mildur]

Thank you for the case number.
I see, that you are using the community edition. In that case, your old backup chains were "per Job backup chains". Even if you only had 1 VM per Job. Community Edition in V11 only had "per Job backup chains".
After remapping them in Veeam Backup & Replication v12, this chains will be synthesized and upgraded to "per VM backup chains". This is an automated process which will start as soon you are map the chain to a backup job:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[For format upgrade using mapping] During the upgrade, Veeam Backup & Replication synthesizes full backups in the per-machine backup with separate metadata files format using the existing backup (the source for mapping). That is why you need enough space on the repository to store full backups. After the successful change operation, the backup used as the source for mapping is placed to the node with the (Orphaned) postfix. After the successful upgrade, you can delete this orphaned backup.

You shouldn't cancel this process. I suggest to wait until it is finished.
To optimize your repository performance, we recommend to have a repository or gateway server in your secondary location. Connecting iSCSI or accessing Share Folder over slow WAN links may lead to performance or stability issues.

Best,
Fabian

[Tom_LeFx]

But I do have a repo Server off-site?
It's just connected via VPN to our Network and thus the wan bottleneck.

I run on community, so WAN accelerator is not a thing...but aside from that, I'd say it's an absolutely normal Setup. No?

[Mildur]

What‘s your backup repository server?
A windows or linux based repository with local disks or a NAS device?

Best,
Fabian

[Tom_LeFx]

It's a centos VM server with local Disks.

It runs on a small, portable system, so that I can transport it to and from the office in case of emergency.

The WAN is fast enough for the usual backups, synthetic full runs well thanks to fast copy and health checks work ok as well.

I use it as Linux XFS repo

[Mildur]

Ah, I apologize. You told about the repository in your first post.
In that case I expect the traffic while updating the chains to stay on the repository Server itself. Do you see traffic on the WAN port after mapping the jobs to the existing chains?

Best,
Fabian

[Tom_LeFx]

Yes, there is constant Traffic going on.

[Tom_LeFx]

And to add to this - after this whole process is done, I would have just removed the old repo from the infrastructure and then removed the server-entry that hosted it.
According to what you posted, I should also delete the backups in the "Disk (Orphaned)" node, which I would have NOT done, because I originally expected this to be just the entries from the repository before changing the server (so basically linking to the same data)

How should I proceed with the orphaned entries? Should I right-click -> "delete from disk" or not?

On a side note as user feedback (although only community edition, so feel free to simply ignore it):
The presumably simple process of changing a network-address of a backup-repository is really not easy and user-friendly in Veeam. At least for me, there are so many unnecessary complications and potential pitfalls there as it seems. I am used to this being a super simple change of IP/hostname in other solutions like Altaro or Acronis - the software figures out that nothing of the data changed and thats that...

[Mildur]

Let me check on that. My assumption is that traffic stays on the repository server and no backup data is transferred for the upgrade process to other components.

How should I proceed with the orphaned entries? Should I right-click -> "delete from disk" or not?

Personally, I would keep them in the backup tree. I know that the user guide mentions to remove them, but I feel saver to keep them. They won't use additional space when they are stored on a XFS repository.

On a side note as user feedback (although only community edition, so feel free to simply ignore it):
The presumably simple process of changing a network-address of a backup-repository is really not easy and user-friendly in Veeam. At least for me, there are so many unnecessary complications and potential pitfalls there as it seems. I am used to this being a super simple change of IP/hostname in other solutions like Altaro or Acronis - the software figures out that nothing of the data changed and thats that...

Feedbacks are always welcome. Doesn't matter if you use the free edition or not.
Normally updating the hostname of a Veeam managed server is an easy process. We have it documented in a KB article. It involves using PowerShell: https://www.veeam.com/kb1905
But with v12 and using the alternative method to remap the backups there is the automatic backup chain format upgrade process you run into.

Best,
Fabian

[Tom_LeFx]

I wish, I would have found/known about the Powershell way. I still don't really get, why this can't be a simple right-click menu operation?

[BackupBytesTim]

I must second that suggestion, other backup software doesn't seem to have this fragile, or maybe it's overly secure, system of databases and metadata files required to keep track of backup data. It's just, specify path to backup data folder, and if there's an existing file there it gets used, if there isn't the software creates a new one. So moving data from one location to another is as simple as change the path and move or copy the backup file with whatever method is most convenient. Which also means if data remains on the same physical server and the address or whatever just changes, it's a simple process of changing the address.

I'm not sure why Veeam needs to keep track of anything in separate databases that need to be updated if backup files are moved, but I do have a hard time believing it to be just "poorly designed" as it would seem ridiculously more complicated from a development standpoint that just having a path to the files and using them if the files are present. Side note, it's also ridiculously complicated from a management perspective compared to other software.