This is the standard features of a node.js based application. Any installed node.js app will have the same folder and files - it is simply that installing node-red globally hides these from you.
The content of the node_modules folder is maintained by npm. You can copy it if you like but if you always do an install, you don't need to. Because of the number of small files involved, copying that folder can take a long time.
The content of the package-lock.json file is similar to the package.json file that is also installed. However, it contains the exact versions of the installed dependencies whereas package.json contains an indication of what version should be installed. So the lock file will produce an exact copy of the installation (it wouldn't pick up any updated module versions for example). Details are in the npm documentation.
The typically created ~/.node-red folder is replaced by the ./data sub-folder in my alternate installer. This is properly called the "userDir" folder and appears as such in the node-red settings. I create it as a sub-folder so that everything is in 1 master folder that is more easily copied or backed-up. That folder holds your node-red settings.js, flows file, credentials, any persisted context variables, the uibuilder folders if you are using that and quite often a bunch of other files and folders. You will also see another node_modules folder in here and this is where the code for your installed nodes goes, typically not the one that is in the parent folder (though you can actually install nodes into that one too which can be useful if you want some nodes that a Node-RED editor can't mess with but can still use).
Yup, that is right and that is where node-red itself puts the modules for installed nodes if you use the palette manager. That is mostly where you want your node packages and any uibuilder installed packages to be.
Nothing of any importance no. npm itself will have updated a few other things but you don't need to be concerned about that.
The whole point of the alternate installer is that everything is together - in significant contrast to the "normal" installation which spreads out files and folders to dark places users will not normally inhabit! 
When you use the alternate installer (or manually reproduce the same type of install), the master folder that you supply to the installer is the single root folder for everything.
The content of the backup scripts in the alternate installer templates/master/scripts folder will also show you where things are that you need to keep/reproduce:
#! /usr/bin/env bash
# Redirect stdout to syslog -
# show with: `sudo journalctl -t nrmain-backup`
# or `sudo cat /var/log/syslog | grep nrmain-backup`
exec 1> >(logger -t nrmain-backup -p local0.info)
# redirect stderr to syslog
exec 2> >(logger -t nrmain-backup -p local0.err)
# --- SET THESE TO THE CORRECT LOCATIONS --- #
NR_SERVICE_NAME=nrmain
NR_SOURCE_PATH=/home/home/nrmain
NR_DEST_PATH=/home/home/nrmain-backup
# ------------------------------------------ #
STARTDATE=$(date +'%Y-%m-%d %T')
echo " "
echo "Starting daily backup of $NR_SOURCE_PATH/ to $NR_DEST_PATH/ ..."
echo "Rotating snapshots ..."
# Delete oldest daily backup
if [ -d $NR_DEST_PATH/daily.7 ] ; then
echo " Deleting oldest daily backup $NR_DEST_PATH/daily.7"
# The slow but understandable way:
#rm -rf $NR_DEST_PATH/daily.7
# The faster way (needs an empty folder)
rsync -rd --delete $NR_DEST_PATH/empty/ $NR_DEST_PATH/daily.7/
fi
# Shift all other daily backups ahead one day
for OLD in 6 5 4 3 2 1 ; do
if [ -d $NR_DEST_PATH/daily.$OLD ] ; then
NEW=$(($OLD+1))
echo " Moving $NR_DEST_PATH/daily.$OLD to $NR_DEST_PATH/daily.$NEW"
# Backup last date
# ISSUE: touch does not support options on synology (busybox) system
touch $NR_DEST_PATH/.dtimestamp -r $NR_DEST_PATH/daily.$OLD
mv $NR_DEST_PATH/daily.$OLD $NR_DEST_PATH/daily.$NEW
# Restore timestamp
touch $NR_DEST_PATH/daily.$NEW -r $NR_DEST_PATH/.dtimestamp
fi
done
# Copy hardlinked snapshot of level 0 to level 1 (before updating 0 via rsync)
if [ -d $NR_DEST_PATH/daily.0 ] ; then
echo " Copying hardlinks from $NR_DEST_PATH/daily.0 to $NR_DEST_PATH/daily.1"
cp -al $NR_DEST_PATH/daily.0 $NR_DEST_PATH/daily.1
fi
echo "Finished rotating snapshots ..."
if ! [ -d $NR_DEST_PATH/daily.0 ] ; then
mkdir -p $NR_DEST_PATH/daily.0
fi
# Set today's date on the current backup folder
touch $NR_DEST_PATH/daily.0
ENDDATE=$(date --iso-8601=s)
# Back up
echo "Performing rsync backup ..."
rsync --archive --hard-links --delete --delete-excluded \
--exclude 'node_modules' --exclude 'data/node_modules' --exclude 'data/externalModules/node_modules' \
$NR_SOURCE_PATH/ $NR_DEST_PATH/daily.0
# Validate return code
# 0 = no error,
# 24 is fine, happens when files are being touched during sync (logs etc)
# all other codes are fatal -- see man (1) rsync
# You can output the result to MQTT or to a Node-RED http-in endpoint
if ! [ $? = 24 -o $? = 0 ] ; then
echo "Fatal: Node-RED daily backup finished with errors!"
#curl --insecure -I 'https://localhost:1880/nrnotify?type=backup&schedule=daily&result=fail'
mosquitto_pub -r -t services/$NR_SERVICE_NAME/backup/daily/fail -m $ENDDATE
else
echo "Finished Node-RED daily backup, no errors."
#curl --insecure -I 'https://localhost:1880/nrnotify?type=backup&schedule=daily&result=success'
mosquitto_pub -r -t services/$NR_SERVICE_NAME/backup/daily/success -m $ENDDATE
fi
# Sync disks to make sure data is written to disk
sync
#EOF
) are welcome.
