Restoring files from backup

ℹ️ Support
, , ,
1

Nextcloud version (eg, 20.0.5): 25.0.2
Operating system and version (eg, Ubuntu 20.04): Docker 20.10.21 on ArchLinux
Apache or nginx version (eg, Apache 2.4.25): 2.4.54
PHP version (eg, 7.4): 8.1.13

The issue you are facing:

Hello. I had an incident recently where I need to restore my filestore (just the directory /var/www/html/data) from backup (due to an error of my own doing, which was not caused by Nextcloud). Judging from what I have found in previous posts on this forum, it would seem I need to restore the database as well, is that correct? Or can I just run php occ files:scan --all once the files are back in place?

Will metadata and file versioning be intact upon restore or are there extra steps I need to take to ensure that it is? (Presumably, that would be why I would need to restore the database.)

Recently I also noticed that the system cron hasn’t been run for nearly a year. It seems the official Docker image available on hub.docker.com does not schedule this to run by default. Naturally, I want to get that runing ASAP but in the meantime, what does that cron do, exactly? Assuming part of it is database maintenance, would the fact that it has not run eliminate the need to restore the database due to the lack of any pruning?

If I do need to restore the database, I will need to make sure that only the tables affecting files is restored. The backup is nearly a month old, and I have calendar and app data that has been stored since. So I would appreciate some instruction on making sure that only the relevant tables are touched.

2

Nextcloud is an application managing both files in a storage and file records in a database… other records exists only in the DB a(as you point out calendar and contacts)… if you want “restore” which by definition reverts an application to specific point in time then you need to restore both parts and loose changes performed in between…

In your situation having old backup, and new records existing in undamaged DB, restoring only the files might be a good alternative to full restore. running occ files:scan --all and occ files:cleanup should fix issues with the files… given the assumption a file version is a file with special-crafted filename I would expect versions state is good as well (reverted to the state of backup). AFAIK metadata lives in DB so it should survive… Disclaimer: I didn’t test this - just my “educated guess” so you might want to perform a backup your existing state and use it in case restore efforts still brake something…

I would never go this path… there is no supported way to restore only subset of the database and you remain in danger something brakes (long term) and in the future you will never know if some issue results from the tampered database…

regarding the cron - take a look at “examples” provided with official Docker image… we had lot of discussion regarding cron with Docker here in the forum as well…