Actually, it's not recommended to handle those files by hand. Per crontab man page:
Each user can have their own crontab, and though
these are files in/var/spool/cron/crontabs, they are not
intended to be edited directly.
Files under /var/spool are considered temporary/working, that's why they probably get deleted during an upgrade, though a closer look at the cron package's upgrade scripts may shed some light on this.
Anyway, it's always a good practice to back up your cron entries or keep them in a file in your home directory.
I assume you're using crontab -e to create crontab files on the fly. If so, you can get a "copy" of your crontab file by doing crontab -l. Pipe that to a file to get a "backup":
crontab -l > my-crontab
Then you can edit that my-crontab file to add or modify entries, and then "install" it by giving it to crontab:
crontab my-crontab
This does the same syntax checking as crontab -e.
I finally found out why my crontabs and Postfix installation kept breaking after boot. It's a really stupid reason but...
I had /var/spool mounted as a tmpfs RAM-drive.
Sounds idiotic and it is, but I had followed one of the old SSD-tweaks to lengthen the life of my SSD. In doing so, I blindly mounted /tmp, /var/tmp and /var/spool as tmpfs without thinking of the repercussions. I thought /var/spool was like /proc/ or /run/ and that it was only useful for the duration of the session. I was clearly wrong.
To list all cron jobs from all users in your system:
for user in $(cut -f1 -d: /etc/passwd)
do
echo $user
crontab -u $user -l
done
An alternative to your issue would be to place them in cron.d folder and specify the appropriate user per cron as in example:
00 01 * * * user /home/user/user-script.sh
