Adding New NAS Repository

[LThibx]

In reference, I have similar situation as a couple other forum posts:
veeam-backup-replication-f2/change-repo ... 15348.html
And this one as it relates to Cloud Connect:
veeam-backup-replication-f2/what-happen ... 73664.html

I am currently doing backups & backup copy jobs to a QNAP NAS via iSCSI for local backup. 10TB total, 2.5TB iSCSI target for Backup, 5TB iSCSI target for Archive (BCJ)
My VB&R instance (VBR1) is a VM on Win 2012R2 Hyper-V
I have another machine (HV3) with Win 2012R2 Hyper-V that is running as a Veeam Proxy.
Cloud Server with Veeam Cloud Connect.
That HV host (HV3) is the proxy running iSCSI initiator to the QNAP.

I have just built a new TrueNAS box with 25TB of usable storage and created similar iSCSI targets for backup & archive.
I want to switch over my BJs & BCJs to the TrueNAS box, but I do NOT want to move my existing data from the QNAP.
What is the best way to define the new repository, as a standalone Backup Repository, or add both existing & new TrueNAS repository as a Scale Out Repository?
Will my first job to new repository be an Active Full?
And how will it affect my BCJs to my Veeam Cloud Connect instance. Will those have to be re-seeded?

Sorry that I may be repeating some of what has been state in other posts, but I just didn't seem to think there was a good answer to these questions.

P.S. Currently running on VBR & VCC version 10, but as I write this I am upgrading to version 11, and first use o new repository will be on V11.

Appreciate the input.
Lonnie

Configuration
Veeam B&R Enterprise Plus v11.0.0.837
Veeam Cloud Connect v11.0.0.837

[foggy]

Hi Lonnie, basically, if you just need to switch to the new repository without copying existing backups there, use the first link you've mentioned. After removing existing backups from the configuration, you will be able to re-point your jobs to the new location and they will perform an active full during the next run. To comply with the 3-2-1 rule, I would think of pointing backup jobs to one NAS and backup copy jobs to another. As for your cloud copy jobs, those shouldn't be affected as VMs themselves and their IDs will not change, just make sure they are looking at the correct source.

[LThibx]

Hi foggy,
Thanks for the feedback.
But I'm a little bit foggy (excuse the pun...ha!) on this point:

I would think of pointing backup jobs to one NAS and backup copy jobs to another.

My goal is to leave the data in the QNAP iSCSI targets as is (especially the Archive target), and just move my BJs & BCJs to the TrueNAS box.
The BJs in the Backup target will just eventually go out of scope as they will no longer be my backup target.
My Archive target on the QNAP contains 13 months of monthly .vbk files (the most current being a .vbk and .vibs that gets rolled up monthly).
In the past months, I am always having to move the oldest of the 13 month archive to a USB drive in order to get enough space on the target to continue processing.

So going forward I would point my BJs to the TrueNAS iSCSI Backup target, and the BCJs to the TrueNAS Archive target, effectively starting new chains for both on the TrueNAS.
I don't want to use the QNAP as a target for anything going forward (at least not at this time).

And sorry, but i need to re-ask this question:

What is the best way to define the new repository, as a standalone Backup Repository, or add both existing & new TrueNAS repository as a Scale Out Repository?

And:

As for your cloud copy jobs, those shouldn't be affected as VMs themselves and their IDs will not change, just make sure they are looking at the correct source.

Correct source?...This would be the BJs on the TrueNAS iSCSI Backup target, wouldn't it? And will this cause a fresh population of my Cloud repository?

Sorry for asking for more clarification...hard for me to wrap my head around all of this.

Thanks again
Lonnie

[LThibx]

Edit to my previous post (sorry, could not find a way to edit my last post so this is an addendum to that).

Never mind about my questioning of this comment:

I would think of pointing backup jobs to one NAS and backup copy jobs to another.

After re-reading your response, I understand "as it pertains to the 3-2-1 rule'.

And also this:

As for your cloud copy jobs, those shouldn't be affected as VMs themselves and their IDs will not change, just make sure they are looking at the correct source.
Correct source?...This would be the BJs on the TrueNAS iSCSI Backup target, wouldn't it? And will this cause a fresh population of my Cloud repository?

I understand I will need to re-source my Cloud BCJs (actually my local Archive BCJs as well) to my new backup repository.

I think I understand now what to do. Just had to ponder this for a while.
My only remaining question is about the repository type for the new NAS targets (standalone Backup Repository or Scale Out).

[foggy]

I don't see why you would need to add the existing QNAP as an extent to a SOBR - you're not going to use it anymore, right?

[LThibx]

So I thought I would follow-up on this thread and post my results and progress, maybe it will help others.
I performed the following:

• Created new repositories on TrueNAS1 (one for Backup, one for Archives, each different iSCSI targets)
• Backups - Removed backups from configuration
• Backup Jobs - Changed destination to TrueNAS Backup target
• BCJs (Archive not Cloud) - Remove from configuration
• BCJs (Archive not Cloud) - Change destination to TrueNAS Archive target
• BCJs (Archive & Cloud) - Change BCJ source to TrueNAS Backup repository
• At some point during the process above, I also had to delete my SureBackup jobs & associated Application Groups, as I kept receiving messages that those backups were in use

On a side note: In an effort to 'harden' & tighten up access to my repositories on the TrueNAS, I removed NTFS security ACL entries for anything except for an Admin account and the user Id I use for backup for connecting across systems. This included removing SYSTEM. I found that I would receive access denied errors when attempting to connect to these targets, either in Repository configuration or when attempting to access these resources in the BJs or BCJs. After re-adding SYSTEM, all access denied issues were resolved. That puzzles me. So it seems that having the SYSTEM account with Full Control on these resoucres is necessary. Didn't think this would be the case, since the credentials I use to access the repository has full control to the resources on the machine running the iSCSI Initiator. Would love feedback about this.

At current, my primary BJ is processing and is 86% complete. Another BJ & subsequent BCJs will follow.
I will post update when complete.

Lonnie