devdocs/todo.txt

@@ -5,9 +5,12 @@
 todo: test devops as production server with automated backups, upload a range of attachments,  simulate crash and restore etc, run load test then backup etc see disk space consumption and make sure 
 	backup works adn restore works as this is obvsiouly critical.
 	IN PROGRESS: set devops to backup at 10pm tonight
+	attached files to a customer called "A customer I created..." and also to Batz customer and also to bizadmin user (several files)
 	Tommorrow morning download backup, erase all data, restore it, document the process for subscription server
 	Also check the docs I must have documetned it there but if not then document that shit
 
+	Test restore a linux backup to windows 
+
 
 
 CLIENT CHANGS TO DO NOW

docs/8.0/ayanova/docs/ops-restore.md

@@ -30,6 +30,18 @@ Once the AyaNova server is running and has created a database it must be shut do
 
 For all "Server" installations of AyaNova with a separate standalone PostgreSQL server; stop the AyaNova server but do _not_ stop the PostgreSQL server.
 
+##### Linux server
+
+If you followed the installation instructions in this guide to run AyaNova as a service then AyaNova is stopped with the following command:
+
+```bash
+sudo systemctrl stop ayanova.service
+```
+
+##### Windows IIS
+
+If hosting AyaNova through IIS use the IIS Manager user interface to stop the AyaNova website which will in turn stop the AyaNova server.
+
 #### Windows standalone "single" type installation
 
 If this is a single standalone Windows installation configuration that starts a self contained database server, the self-contained PostgreSQL server is stopped automatically when the AyaNova server is stopped so PostgreSQL will need to be started manually from a command prompt in order to restore data to it.
@@ -92,17 +104,34 @@ Windows self contained "single" user installation:
 
 Linux server:
 
+The database backup file must be placed in a location that the 'postgres' user has permission to read from.
+
+On a default Linux Postgres installation a suitable folder is:
+`/var/lib/postgresql`
+
+Copy your `db-xxxxxxx.backup` file to that location before issuing the restore command.
+
 ```bash
 pg_restore -U postgres -c -d AyaNova ~/downloads/db-20211212195504569.backup
 ```
 
 The restore will complete normally without any message if successful.
 
-AyaNova can be re-started at this point, for server type installations restart through the IIS 'site' in Windows or the Service in Linux. If using the desktop single Windows installation, stop the PostgreSQL started in the earlier restore step by typing `ctrl-c` in the PostgreSQL console window then start AyaNova from the desktop launcher as normally.
+### Restart AyaNova server
+
+AyaNova can be re-started at this point, for server type installations restart through the IIS 'site' in Windows or the Service in Linux.
+
+If using the desktop single Windows installation, stop the PostgreSQL started in the earlier restore step by typing `ctrl-c` in the PostgreSQL console window then start AyaNova from the desktop launcher as normally.
 
 ### Verify the data
 
 1. Verify database: login to AyaNova, check that the most recent data that should be in the database backup is present
-2. Verify attachments: First examine the list of attachments that AyaNova knows about in the database by opening the Adminstration -> Attached files. This list shows the attachments that AyaNova _expects_ not necessarily what is physically present so select an attachment listed to open the record that attachment is connected to and confirm the physical file is actually present by opening the file in the attachments area of the form. If the file won't open verify that the attachment files are restored to the attachments folder where AyaNova expects to find them and not in another folder or sub folder and check again and also verify it's not just an issue with that one attachment by checking or more other attachment files in the same way.
+2. Verify attachments: First examine the list of attachments that AyaNova knows about in the database by opening the Adminstration -> Attached files. This list shows the attachments that AyaNova _expects_ not necessarily what is physically present so select an attachment listed to open the record that attachment is connected to and confirm the physical file is actually present by opening the file in the attachments area of the form.
+
+If the file won't open verify that the attachment files are restored to the attachments folder where AyaNova expects to find them and not in another folder or sub folder and check again and also verify it's not just an issue with that one attachment by checking or more other attachment files in the same way.
 
 There is no need to shut down the server if the attachment files need to be moved to the correct folder.
+
+### Cleanup
+
+Once data is verified and attachments are confirmed don't forget to cleanup any temporary copies made of the Data folders and any copies of the backup or zip files to maintain security,  save space and ensure no confusion in future if it becomes necessary to restore again.

docs/8.0/ayanova/mkdocs.yml

@@ -7,7 +7,7 @@ theme:
 site_name: AyaNova manual
 site_dir: '../../../server/AyaNova/wwwroot/docs'
 strict: true 
-copyright: Copyright © 2022 Ground Zero Tech-Works Inc. REV-2022-09-20
+copyright: Copyright © 2022 Ground Zero Tech-Works Inc. REV-2022-09-21
 extra:  
   generator: false
 # Extensions