Backup policies to recover from quiet/insidious changes by insiders

I'm exploring backup policies such that if there's insiders quietly
altering them, we can skip the 'bad' changes:

Day 1: the initial good build
Day 2: legit/good updates were made
Day 3: an insidious/malicious update were made
Day 4: good legit updates/changes were made

We want to restore till Day 2, skip Day 3, restore Day 4.
Was told a GFS scheme as above will help but I tend to think
a mix of incremental plus differential backups is needed.
Pls comment.

For DB, is it better to backup the OS files of the DB or take dumps & backup
the text dumps?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David FavorLinux/LXD/WordPress/Hosting SavantCommented:
Q1) Likely better to trust your backups, rather than a GFS scheme.

Q2) Whether you backup raw files or dump individual databases... many considerations about which is best...

Consideration #1) To backup raw files which are consistent (no corruption), you must stop your database instance.

The way I do this (using MariaDB as an example), is to...

1) rsync -av /var/lib/mysql /var/lib/mysql-dump while mysqld is running.

2) Place all sites in maintenance mode, show they show a nice message, rather than database connection error...

3) service mysql stop

4) rsync -av /var/lib/mysql /var/lib/mysql-dump - this only picks up changes now, so this rsync runs very fast.

5) service mysql start

6) Take sites out of maintenance mode, back into production mode.

Consideration #2) Restores of raw files are blazing fast compared to dropping + restoring individual databases.

Consideration #3) When working with raw files, all sites revert to time of backup, rather than just one site for individual backups.

My tendency is to do both.

I run all sites in LXD containers, so I backup the entire bootable container + then also backup each individual database, so I can restore an entire container or just one database.
David Johnson, CD, MVPRetiredCommented:
AFAIK, you can't skip restoring a incremental backup when restoring to the latest backup.  You may be able to restore individual files using the full chain.
sunhuxAuthor Commented:
understand incremental wont help but I'm looking at a combination of incremental plus differential
David Johnson, CD, MVPRetiredCommented:
You know the difference between the two.  As I said previously restore to the day before the incident using base and differential of that date or base and incrementals to that date.
Now you can open the backups and restore FILES overwriting older files except the affected files.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sunhuxAuthor Commented:
> may be able to restore individual files using the full chain
Ok, missed the above line
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Storage Software

From novice to tech pro — start learning today.