Best practices for backing up necessary site files before updating D8 using the command line

If you have all of the Drupal source code and modules in a Git repository, you should not need to back up the entire document root. You would want to back up the sites/default/files directory (or wherever you have the public/private files such as images that you have uploaded). And you would want to make sure that all of the Git files have been committed and pushed to a remote repository.

That would cut the number of files you need to back up down to what the Backup and Migrate module would back up. However, you would definitely need to make sure you have your Git repo updated, so that if you need to back out the update, you could do that.

And yes, the database!

I've written and re-written the backup and import script for Drupal database + files used by my team in a production environment (written as a CLI script in Bash). As jhodgdon suggested, we have no need to backup the entire drupal root directory, since our code is stored in git. I chose to forego the backup_migrate module also because I wanted a solution with as few dependencies as possible where php + drupal + drush was not required (the script requires only the mysql client, which comes with the mysql and mysqldump cli commands). This is especially useful if you want to run the script in a containerized environment with a minimal container image. YMMV, but this made backup and imports much simpler from a system administrator perspective (not necessarily a drupal-centric developer perspective though).

A few other comments/suggetions not already mentioned:

• First and foremost, it is worth mentioning that since database and managed files are two separate systems (file system and database), there is no way to absolutely guarantee your backup will be perfectly in sync (short of hosting both database and files on the same host and using atomic file system snapshots). I have seen corrupted backups that did not restore completely properly but that is very rare. In those cases, we use the closest backup, which is usually not a problem since we take backups every 2 hours.

• Since I'm completely bypassing drush and drupal, I need to have the database credentials stored elsewhere. This is not a problem since mysql client has the [client] ini config section in /etc/my.cnf or ~/.my.cnf, so do not have to specify passwords on the command line (insecure).

• Depending on your use case, you probably do not need to backup every database table such as cache tables and other similar tables (batch, queue, session, watchdog, etc), since most of those either will re-generate or are environment-specific. This can greatly reduce file size as well as script run time.

• If your drupal site generates image thumbnails and similar "generated" files that are saved into drupal managed files, you can optionally exclude these as well since they can be regenerated. This will save additional space on backup files. This can add up when you are saving and archiving backups on a regular basis.

• At various times, we've stored our managed files in different backends, from the local file system to NFS to Amazon S3, which the script had to accommodate. At minimum, the script needed to accommodate specifying the paths to drupal public and private managed files. For importing files, using rsync instead of a naive copy will result in a much faster file importing experience (equivalent for S3 is the "aws s3 sync" command of the aws-cli)

• Since the majority of drupal managed files are images, which already use their own compression algorithms (JPG, PNG, etc), running compression (gzip, zip, etc) on the files is mostly wasted CPU time for no size reduction. Therefore, I only compress the SQL file(s) for the database (huge file size reduction), and leave the drupal managed files as-is (your use case may differ though). I then archive (tar) those together to create my single backup archive file. My import script needs to understand this custom archive format in order to extract and import the database and files.

• When you restore your drupal managed files, you will very likely have to change the file system user and group (chown -R myuser:mygroup /path/to/files) so that your web server user has the necessary read/write file permissions. If you run SELinux, you may also need to change the context (chcon) depending on where your files are located.

• Performing backups and imports requires a very large amount of disk space in order to save and archive to / extract and import from a single large archive file. Ensure your environment has more free disk space than at least two to three times the size of your database + managed files.

• Lastly, to speed up the run time, my script forks several processes to backup or import managed files and database tables in parallel. This is not strictly necessary but certainly helpful.

If all the above is making you reconsider writing your own backup/import solution, then perhaps a pre-existing solution like backup_migrate might be more appealing to you. If still interested, I can try to find the time to make my script generic enough to post to github (with a huge zero-liability, zero-support disclaimer).