For IP address transfer/takeover to work the network has to be the same. Other clustering solutions work like this.

Planning a Mirror Virtual IP (VIP)

If by fake you mean not the normal OS level clustering solution that is true. It is an app specific solution.

If the cost of the 2x storage is an issue maybe a deduplicating SAN would reduce the cost at the added risk not having redundant storage.

If at the OS layer you used LVM and XFS you could just add a LUN to the volume group and grow the filesystems. This can be done with everything up.
The backup solution for me determines what a large file is. For me that is anything over 1 terabyte. We use External Backups.
Most backup solutions only have one process per file. This means fewer and larger IRIS.DATs will always be slower to backup and restore than more and smaller IRIS.DATs.
The growth pattern needs to be understood. If it is going to just grow forever it has to be broken apart and it will be easier while it is small.
In your place I would upgrade to the 2024 version and explore Multivolume Databases.
8K IRIS.DATs have a max size of 32 Tb though Intersystems is working on this.
 

A low impact way to do this would be take a SAN snapshot of production and mount the snapshot in test.

Intersystems discusses this in External Backup.

The easy way to retain some database is mount them from a different set of disks/filesystem.

If you have a DR mirror but not a SAN you could just shutdown the DR mirror and do a cold backup.

If test is a separate mirror the whole test mirror will have to be refreshed due to mirror headers. If test is part of the same mirror as production then the data is already there.

In two really key ways multi-volumes datasets don't allow you to escape limits you might want to escape.
The max size of a multi-volume dataset is the same as a single file - 34 TB (33553904 MB) for 8K database. Intersystems is working to increase the max size.
An integrity check also treats it as if it was a single file. This is only going to be more of an issue as the max size increses.

Guessing the upgrade did iris start [instance] nostu to not run any user code on startup.
iris help start
                            **** iris usage ****
Syntax:
        iris start <instance name> [parameters]
Description:
        Run the instance's irisstart procedure to bring InterSystems IRIS up.
Optional parameters:
        quietly -> non-interactive, with minimal dialog
        nostu   -> don't run startup routine (^STU)
        help    -> list supported parameters
        EmergencyId=username,password -> start up in emergency mode
        Any other value is taken as a configuration file name with '.cpf' appended.
        If a configuration file is not specified, the file 'iris.cpf' is used.
Example:
        iris start mystuff quietly      <- uses file 'mystuff.cpf'
Notes:
        Some instances might not have support for a particular parameter,
        or a new parameter could have been added.  For a list of supported
        parameters for a specific instance, type:
                iris start <instance name> help