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.
 

I think you can q to exit that debug mode.

1.9Tb will be days assuming ssd storage and slower if not.
I would test a small amount during a low period.

Since you are on Cache still make sure it is ok to compact/truncate with your version.
Run an integrity check after to validate the DAT.
Expect large wij growth.
Do @Enrico Parisi's suggestion of a small amount first during a low utilization time.
Mirror and shadow targets have to be done separately.

The only thing from the preinstall doc that looks like a service is a webserver.

You might look at this Estimating Memory Requirements.

Did you do this? Semaphore Deletion Setting

There are some clear warningssugestions in the documentation but very reasonable.
Customizing Start and Stop Behavior with ^%ZSTART and ^%ZSTOP Routines - Design Considerations
Using the ^ZMIRROR Routine
One issue to consider is on Failover or DR mirrors the code might need to be in ZMIRROR not ZSTART.

I don't think you need more than normal production code awareness.

I don't have the linux version running now but the docs say

systemctl status ISCAgent.service
or if you have ISCAgentCtrl
ISCAgentCtrl status
Usage: ./ISCAgentCtrl start|stop|restart|status|usage

This looks like what you want.

https://cedocs.intersystems.com/ens20171/csp/documatic/%25CSP.Documatic....

I would consider upgrading to the latest Cache before using compact and truncate.
Run an integrity check after to validate it didn't cause corruption.

Read this to see if applies

https://www.intersystems.com/product-alerts-advisories/alert-possible-da...

Cache 2018.1.8 is supported on Redhat 8
This should get you started - Installing Caché on UNIX®, Linux, and macOS

An easy way is setup Operating System–Based Authentication
in %sys
^SECURITY
12) System parameter setup
2) Edit authentication options
Allow O/S authentication? Yes   

This allows scripts like this

iris session ${INST} -U %sys << EOF

w "stopping the mirror 1 is sucess: " zw ##class(SYS.Mirror).StopMirror("MIRROR") h
EOF
Once an IRIS LDAP account exists it does not appear to be different local account.

You can do this too:
iris session [instance] -U [namespace] tag^routine

Set file=##class(%File).%New("[path/filename]")
Write file.Size
Do file.Open("AWS")
Do file.WriteLine("This is a second line of text")
Write file.Size
do file.%Save()
set file = "" // Close file

This works for me

Yes there is a way since I have seen it.

The ZLOAD and ZREMOVE commands are combined. Here is a sample I was sent.

zr
zl
showAdmins() n rs1,rs2,rc1,rc2,$NAMESPACE,user,adminrole,roles
  s $NAMESPACE="%SYS"
  s rs1=##class(%ResultSet).%New("Security.Roles:List")
  d rs1.Execute("*","%Admin_Manage:U,%Admin_Operate:U,%Admin_Secure:U")
  f  s rc1=rs1.Next() q:rc1=0  d
  . s adminrole=rs1.Data("Name")
  . s rs2=##class(%ResultSet).%New("Security.Users:List")
  . d rs2.Execute("*",adminrole)
  . f  s rc2=rs2.Next() q:rc2=0  w rs2.Data("Name"),"|",rs2.Data("Roles"),!
  q
d showAdmins

The host, storage and DB engine don't influence the gref count at all. Only what the code does.
If you do a set,kill or write that is a gref.
The host, storage and DB engine determine the limit of grefs per second.
Faster storage is always better.
More memory (larger global/routine buffer) is always better.
Faster cores are always better. More cores are better if there is work for them to do.
Newer versions of IRIS (DB engine) are always better.

GLOSTAT will give you some numbers
https://docs.intersystems.com/iris20221/csp/docbook/Doc.View.cls?KEY=GCM_glostat

Vertical Scaling IRIS
https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GSCALE_vertical

What does openssl version show? Guessing 3.x since that is the version that ships with Ubuntu 22.04.

Bob is right, try on Ubuntu 20.04 instead. This shows the downside of IRIS being dependent on OS packages.

Have you tried URL encoding? CON would be equal to %43%4F%4E and con would be %63%6F%6E

I don't know a way that you can do that.

You can run  ^%GSIZE against a specific CACHE.DAT

I have 21 instances of Cache running on a single server.

There are a lot of pluses: simpler cpf, database snapshots, easier downtime negotiations

I would manually specify memory since you likely have very few simultaneous users.

Here is a link Sizing System Memory for Caché

If your session is text you might make a look at a tool like screen that is available for Unix based systems.

You can compact and truncate the database while IRIS is up.

Compacting a Database

Truncating is the next section