a musthave - if only the scrolling got fixed already 😇

Backup on different levels, one of my clients who I would say has similar ifrastructure uses following approach:

• backup on the vm level - backing up snapshot of the entire virtualization guest - at least once a week, always before update/upgrade. These can be big - consider ZFS pool w/ compression and deduplication active - but that is also hw intesive. On the other hand, I don’t think you need to keep more than last two successfull backups.
• filesystem level - run rdiff-backup against the / of the filesystem several times a day. SInce it is essentially versioning, you are only backing up new changes. No zetabyte needed here, ext3/4 will do.
• drop database somewhere ideally several times a day - even if there are no incidents, your developers will love you.

The recovery strategy is as follows:

• pull the guest out of the last vm backup
• sync up the files from last rdiff-backup run
• discuss w/ the developer DB recovery - or just recover the last backup and hope for the best…

I use my laptop a lot (usually plugged in)

Warning : I’ve used to fix apple computers back in the day when there were still things to fix, and if this had happened to an Apple device and it had less than 50 cycles on it and was over 6 months from purchase (meaning it went less then 50x under 50% of your full battery capacity), they would refuse to replace it saying it is user’s fault. Nbooks with NiMh batteries could stay connected to power forever, notebooks with Li-ion batteries need to “excercise them”.