If Bob's suggestion doesn't fix your problem, I recommend opening up a WRC issue about this. In addition to the encryption keys, you could have an issue with the SSL setup (SSL is required for mirrors if you're using journal encryption).  For what it's worth, you could take a look at my article about creating an SSL-enabled mirror with keys/certificates generated using the Public Key Infrastructure to see if that helps.

Larry, you probably want to open up a WRC issue to address this. The first step will be to try to figure out if the problem is with Caché or with the operation specifically. To do so, you'll want to try to make this connection in a terminal. If any of these statuses are not successful, you should 'd $system.OBJ.DisplayError(<variable>)' and collect the local file you set up with the trace mask:

set ssh=##class(%Net.SSH.Session).%New()
do ssh.SetTraceMask(511,<newlocalfile>)
st1 = ssh.Connect("<SFTP HOST>","22")
st2 = ssh.AuthenticateWithUsername("<UserName>","<Password>")
st3 = ssh.OpenSFTP(.sftp)
st4 = sftp.Put("<local path and filename","<remote path and filename>")

Do you have a local instance installed that you want to connect to? If so, the IP would be 127.0.0.1 (or localhost). You shouldn't need to configure the others unless this is a specialized instance setup. If you simply installed a development instance and are using that version of Studio, there is nothing you need to actually setup. As for the docs, maybe this section will be better. It also may be useful for you to start with the Using Caché Studio book.

You don't create new servers/namespaces in Studio. You can add connections to remote servers by going to the icon, and instead of choosing Studio, choosing 'Preferred Server' -> 'Add/edit'. If you're just trying to create a new namespace that you can access in Studio, you should use this documentation. Studio is to work with code on pre-existing servers/namespaces. If you just want to access the SAMPLES namespace, you can get to it from File -> Change Namespace (or F4).

Dmitry makes some good suggestions above. I would suggest collecting a 24-hour pButtons report on this server (you can also collect a 30 minute one simultaneously so you have some data more quickly) and opening a WRC issue with that data. It will contain the mgstat data reference, along with performance metrics at the OS level, among other things. Performance issues are not generally quick to solve, and take a bit of time reviewing a lot of data before conclusions can be made. 

I will also say that, if this is happening frequently, it's likely your disk is simply too slow for the amount of work the write daemon needs to do.

You could use the 'List' queries in Config.MapGlobals, Config.MapPackages, and Config.MapRoutines, match those to the database that you are copying from, then change those specific mappings to the new database. Here is an example that will change mappings for routines in the USER namespace from the USER database to the TEST database:

s startdb = "USER"
s enddb = "TEST"
s ns = "USER"
s rs=##class(%ResultSet).%New()
s rs.ClassName="Config.MapRoutines"
s rs.QueryName="List"
s sc=rs.Execute(ns) 
If 'sc Do DisplayError^%apiOBJ(sc) Quit
  while rs.%Next() {
   if (rs.GetDataByName("Database")=startdb) {
   s Properties("Database")=enddb
   d ##class(Config.MapRoutines).Modify(ns,rs.GetDataByName("Routine"),.Properties)
   } 
}
  d rs.%Close()
  q