@kkyyww theoretically, yes...you could. When you re-add the Repository to Veeam, you should have an option to scan it for backup files on it.
 

They would show under Orphaned, if memory serves. And, you could then restore from those files. I haven’t tried this. Maybe someone else can chime in who may have. May I ask why you wanna disconnect your iSCSI LUN then reconnect it? To maybe have an ‘offline’ copy? Just curious.

I’m worring about if I just mount the old iSCSI LUN of the same volume, would have some issues with same volume UUID ?

Do you have enough space on your NAS to create a small 2nd LUN to connect to your Veeam server and test what you’re wanting to do? When you remove the Repository, Veeam removes services it installs when you added it initially. When you re-add it, it reinstalls those services and, if the box is checked as shown in my screenshot above, detects any backup files on the storage. There should be no conflicts.

The OS would care, if you mounted it to the same server. But Veeam is working with files & paths here, so your problem would be upstream.

Your subject title suggests rolling back to a previous snapshot, in which case you would only have one LUN that would be unexpectedly older by Veeam and thus break every chain when Veeam attempts a new backup. But provided you presented the snapshot as a new LUN, you’d just have to deal with the issues such as the UUID duplicating, and then mounting as a new volume to scan by Veeam

Good point there @MicoolPaul . I was only thinking on the VBR side, not server the LUN is connected to. 

Ummm, maybe I can build another Veeam workstation, just for restoration from old iSCSI snapshots?

I don’t see why not. But here’s a question, why use iSCSI snapshots when you could use a native backup chain?

@MicoolPaul

1. Much simplier backup plan with VBR, I’m still quite confusing with VBR’s GFS, and I read an article from @coolsport00 , I may end up with hundreds of incremental ? Also I can’t take months to do PoC on this
2. I’m very familiar with iSCSI snapshot and replication
3. I think this should take much less space than Veeam GFS (I know my version is not real GFS, but close enough for my own need)
4. With this trick, I would have 365 days retention with 12 monthly iSCSI snapshots while keep the VBR backup-chain short and clean

GFS can be a bit tricky...I’m with you there. I spent a bit of time wrapping my brain around it before writing that article Yes, GFS files are fulls (though incrementals are not), so you do run into needing quite a bit of storage space if you store files for a while. 

What OS is the server that’s your repository? What filesystem and block size is the iSCSI LUN configured as?
 

If you can use synthetic fulls with forward incremental then you’ll see no space different more or less with having so many full backups.

I thought you might be looking at snapshots to protect against an attack on the host or ransomware etc.

Just tested mount the iSCSI snapshot without dismount the current repository,  it just works, no complain about duplicate GUID

Nice! :) 

Hello @kkyyww 

Why don’t you consider Veeam extract Utility? 

Veeam Backup & Replication comes with an extract utility that can be used to recover machines from backup files. The extract utility does not require any interaction with Veeam Backup & Replication and can be used as an independent tool on Linux and Microsoft Windows machines.

The extract utility can be helpful, for example, if it is written to the tape next to machine backup files. In this case, you get a possibility to recover machines from backups at any moment of time even if backups are removed from Veeam Backup & Replication or Veeam Backup & Replication is not installed.

https://helpcenter.veeam.com/docs/backup/vsphere/extract_utility.html?ver=120

@kkyyww : I would not recommend to use snapshots on the iSCSI LUN just to keep extra restore points. It could be an extra ensurance for ransomware or so. But just to keep extra restore points, just keep to the working of Veeam. Just create GFS points. As @MicoolPaul already mentioned, it you use XFS/REFS with fast cloning and synthetic fulls (which is default created with GFS) it doesn’t consume much storage (more or less the same as an incremental). No issues to restore something, because everything is natively setup. I recommend to use always at least 1 restore point as weekly GFS even if you just want to keep only monthly GFS - otherwise the incremental chain will become too long.

@Nico Losschaert yes I have created a new REFS pool and will test how the synthetic full perform. Easier operation than snapshot dirty tricks I think.