The general guide from Matomo:
https://matomo.org/guide/tracking-data/import-server-logs/

The importer will fail silently if you lack permissions.  It's a read error.

The following worked:
sudo python3 /var/www/littlefurnace.com/matomo/misc/log-analytics/import_logs.py    --url=https://littlefurnace.com/matomo  --idsite=1    --recorders=4 --enable-http-errors --enable-http-redirects   --enable-bots /var/log/apache2/access.log  --token-auth=REDACTED --debug-tracker

​

1. The Matomo code base shows their latest stable version is 5.0.3. https://builds.matomo.org/
2. The Docker code is a community project. Matomo doesn't make it. That code is here:
   https://github.com/matomo-org/docker/issues
3. The combination of 1 and 2 are auto pushed to here https://hub.docker.com/_/matomo This version will have the stable release, Matomo 5.0.3, wrapped in a community based release of the Docker set up

Please note that the Matomo Docker images do not form part of Matomo's automated security assessments. They only do this for the Matomo codebase itself.​​​​

To be secure:

• Build your own docker image to be used for your Matomo deployment. For our security-focused users, this is going to be the best method available as it ensures you have complete and full control of all dependencies and packages installed in the container itself or
• Update the vulnerable packages in the docker image and save the patched image as your base image for deployment. This is likely the easiest solution if you don't want to go through the process of building your own docker image from scratch. The process of updating packages and committing the chanDockerges to the base image is out of the scope of our support, but there are several guides online that you can use to make the necessary changes to your docker image.​​​

Matomo does not provide hands-on, in-depth support for Docker but it is a popular way to deploy.

The general concept is similar to a multi-server Matomo model, so these diagrams are useful: https://matomo.org/faq/on-premise/how-to-configure-matomo-for-high-availability-multi-server-environment/

Three ways to upgrade Matomo without losing data (this is for sites with more than 1M hits/month).
Two of these are described here
https://matomo.org/faq/how-to-update/faq_20844/


Option 1 -
Creating a copy/replica of the existing production environment with a test database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Update the config file to point to a testing/dev Matomo database
3. Update all plugins on this server
4. Update the database credentials to point to the production database
5. Update DNS records or Load balancer config to point to this new server
6. Run the core:update command to update the productions database

This option has the benefit of being able to update the codebase without directly making changes to the production environment, but doesn't allow for 1:1 planning for any potential issues with the production database.

Option 2 -
Creating a copy/replica of the existing production environment including the Matomo database
The steps for this would be as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
   (This is our opportunity to look for potential issues and find an accurate time to plan for the production update)
6. Once we've tested the update, we update the database details to point to the production database
7. We can then update the DNS records or load balancer config to point to the new server.
8. Run the core:update

This option has the benefit of updating the codebase without impacting the production environment, planning for any specific issues that might arise from updating the production database and have mitigation strategies for that. It also allows for an accurate estimate of the required maintenance window for the production database update.

This strategy does not allow for minimal downtime and tracking during the update would need to use either the Queued Tracking or Log Analytics method mentioned here: https://matomo.org/faq/how-to-update/faq_20844/

Option 3 -
Creating a copy/replica of the existing production environment including the Matomo database and migrating to this replicated setup once updated.
The steps for this would be similar to option 2 and are as follows:

1. Create a replica/copy of your existing production server for Matomo
2. Create a copy of the production Matomo database
3. Update the config file to point to the copied Matomo database
4. Update all plugins on this server
5. Run the core:update command to update the copied production database
6. Once we've tested the update and ensured that everything is working, we can then update the DNS records or load balancer config to point to the new server.
7. We backfill any tracking data that was sent to the old production instance since the replica was made

This strategy allows for the most amount of planning and doesn't require specific timeframes to complete the update. Since we can backfill the data as much as is necessary using the Matomo web server access logs (These need to be enabled in the web server configuration). The update can happen while the existing production database is running and the switch can be made once this replicated setup is fully updated and ready. The backfilling of tracking data can also be tested while running in parallel to the existing production setup to check for any potential discrepancy in the replayed tracking data.

Here are all four ways to track in Matomo without a consent banner: https://matomo.org/faq/new-to-piwik/is-there-a-cookie-less-alternative-to-google-analytics/
============
How to accomplish your goal of 100%? Because Matomo has been developing in parallel with GA since 2008, we have had time to create four completely separate solutions to this objective:

• First way is server side. If you write your own mobile applications, or build your own ECommerce backend, you can track your visitors right there, in the server. Use our SDKs: PHP, C#, Java, or in mobile, use iOS or Android SDKs).
• Second way:
  If you have access to your server, you can use Log Analytics to look at server logs in Apache or Nginx.
  https://matomo.org/guide/tracking-data/import-server-logs/
  https://matomo.org/faq/how-to/measure-100-of-ecommerce-interactions-using-server-side-tracking/ ( I look forward to hearing more about the guide from Piano, where they dis-recommend this strategy)

Notice that these first two strategies are completely outside of the browser. So Chrome/Safari/Brave/Firefox can do whatever they want - your stack is future proof: Chrome browser can change in 2024 and you are still fine. Ad blockers can come in and you are still fine.

• Third way: Our JavaScript tracker lets you easily disable cookies for all visitors. And you can disable very gradually. If you go to our main page, and look up Privacy in the footer, there are guides to let you dial it back: scramble part of the IP address, scramble the entire IP address, … in the visual interface it is easy to click and unclick a few things so that you can run a landing page with NO CONSENT BANNER. In France, follow the CNIL guide: https://www.cnil.fr/sites/default/files/atoms/files/matomo_analytics_-_exemption_-_guide_de_configuration.pdf Now you have NO banner. That’s the dream! 🏆 You can get almost every visitor.
• Fourth way: Our JavaScript tracker lets you run hybrid.
  Matomo has many options in its configuration. One common way to ethically use Matomo to gather data is:
  1. Show your visitor a banner for consent before using tracking cookies and/or measuring user analytics and then
  2. Track the visitor without cookies if they have responded "No" to the consent banner
  If you want to completely skip using tracking cookies, you can Skip 1 and go directly to 2.
  Please see more options in our general guide: https://matomo.org/guide/manage-matomo/privacy/

Matomo is a classic LAMP stack in most cases: Apache (or similar) web server creating the APIs, running in Linux. Windows works too - but the documentation defaults to giving Linux syntax.  PHP language in the backend and persistent data with MySQL database (or similar: MariaDB, AWS MySQL, Azure Windows MySQL all work).

Most of your Matomo deployment is just generic code: you could erase it and lose nothing. The precious, precious data, lives entirely in the SQL database. 

This is great because it's portable. And because MySQL database is mature tech, there are tons of experienced admins and tons of online documentation.

Here are some official migration guides: https://matomo.org/subcategory/migrate/

If you move your deployment, don't forget to also move the settings files.  These are a small flat file, less than 1MB in many cases. But that's it.  You can discard all of the Matomo PHP/Python/JS code and redownload from Matomo any time you need it.