Note
Because all EAS developers log into the various EAS Linux servers using the same login credentials (`dev` and `postgres`), the information below could be (re-)derived at any time by examining the complete shared history by running the `history` command from an SSH session, for example, while logged in to the EAS DEV database server ((virtual) machine).

Step-by-step Guide

...

Each EAS database in each of the environments is backed up every night, so there is always a SQL-dump file available for database restoration.
Before an EAS database can be restored, the SQL-dump file must be available on the target EAS database server. One way to do this is to copy the SQL-dump file from the source EAS database server to the target EAS database server by way of your desktop personal computer (PC). One way to do this is to use FileZilla.
These are example SQL-dump files for the `eas_prod` and the `sfmaps_prod` databases:
`easproddb.sfgov.org-eas_prod-20170613.dmp`
`easproddb.sfgov.org-sfmaps_prod-20170613.dmp`
Copy the SQL-dump file(s)
FROM: source EAS database server (`/mnt/backup/pg/daily`)
TO: desktop PC
Copy the SQL-dump file(s)
FROM: desktop PC
TO: target EAS database server (`/var/tmp`)
Log in to the target EAS database server using SSH.
Copy the database restore shell script from your home directory to the target directory. This is only necessary the very first time that you do this.
`cp restore_dbs.sh /var/tmp/`
Move into the target directory.
`cd /var/tmp`
Change the ownership of the database restore shell script. This is only necessary the very first time that you do this.
`sudo chown postgres:postgres restore_dbs.sh`
Change the ownership of the SQL-dump file(s). The following examples use the SQL-dump files from 2a above.
`sudo chown postgres:postgres easproddb.sfgov.org-eas_prod-20170613.dmp`
`sudo chown postgres:postgres easproddb.sfgov.org-sfmaps_prod-20170613.dmp`