Restoring backup overwrites new data

ℹ️ Support
1

Nextcloud version (eg, 12.0.2): Nextcloud 15.0.5.3
Operating system and version (eg, Ubuntu 17.04): Ubuntu 16.04.3 LTS
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.18
PHP version (eg, 7.1): PHP 7.0.28

The issue you are facing: When I restore a full VM backup (where I have nextcloud installed) and the synchronization starts, the old backup files overwrite the new modified files on the clients.

Is this the first time you’ve seen this error? (Y/N): N

Steps to replicate it:

  1. Restore VM backup
  2. Let Nextcloud synchronize with the clients
  3. Old backup files overwrite client modifed (more up-to-date) files

The output of your Nextcloud log in Admin > Logging:

The log is too big to be posted here, but there are no errors at the time

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):


<?php
$CONFIG = array (
  'instanceid' => 'oc4ui9u0oaju',
  'datadirectory' => '/nextcloud/home',
  'htaccess.RewriteBase' => '/nextcloud',
  'dbtype' => 'mysql',
  'version' => '15.0.5.3',
  'dbname' => 'dbnextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'installed' => true,
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'onlyoffice' =>
  array (
    'verify_peer_off' => true,
  ),
  'filelocking.enabled' => true,
  'redis' =>
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'dbindex' => 0,
    'timeout' => 1.5,
  ),
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'mail_from_address' => 'nextcloud',
  'mail_smtpmode' => 'smtp',
  'mail_smtpauthtype' => 'NTLM',
  'auth.bruteforce.protection.enabled' => false,
  'maintenance' => false,
  'loglevel' => 0,
  'theme' => '',
);
(END)

The output of your Apache/nginx/system log in /var/log/____:

I guess this is the error log. This is its content:

[Thu Mar 14 06:25:03.624707 2019] [mpm_prefork:notice] [pid 3074] AH00163: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g configured -- resuming normal operations
[Thu Mar 14 06:25:03.624755 2019] [core:notice] [pid 3074] AH00094: Command line: '/usr/sbin/apache2'
[Thu Mar 14 09:55:27.965308 2019] [autoindex:error] [pid 14891] [client 192.168.200.1:57686] AH01276: Cannot serve directory /var/www/html/nextcloud: No matching DirectoryIndex (none) found, and server-generated directory index forbidden by Options directive
2

That is usually quite common when restoring backups regardless of the solution. Always restore to a new location. Basically you will get conflicts of synced files and files might get overwritten. Perhaps this should trigger a conflict on the client. But it might not.

Have you check what you have on the client? OR have you only checked the server?

3

I’ve checked both, and while the client has files that have been modified since the backup date, the Nextcloud client ignores this and pushes the old ones in the server over them, being synchronized on the clients too.

4

Any other idea?

5

What was the intention of your restore?
Get back just one/a bunch of file(s)?
Set the whole thing back in time?

Did you look at that fingerprint thing? occ maintenance:data-fingerprint

https://docs.nextcloud.com/server/stable/admin_manual/maintenance/restore.html?highlight=fingerprint

1 Like
6

I didn’t do any of this, because I’ve restored a full backup of the VM where Nextcloud is installed.
In case I got a virus, or a problem with the VM filesystem, or the VM host, and I couldn’t just restore Nextcloud, or I just wanted to restore the service as soon as possible.

After doing it, the files that an user modified locally in his computer, while not being able to access the Nextcloud server, don’t get synchronized with the server, replacing the old ones present in the backup, but the opposite happens. Old files, present in the backup overwrite the updated on the client.

The purpose is to restore the service as soon as possible, retaining the backup files, while not pushing them over the client files, if these are more up to date.

I think it would be the normal behavior of the program.

7

Maybe the reason for this is, that the modification dates of the files on the server have been newer than the ones on the clients. How did you restore your VM? Did you restore the raw vdisks or was that some kind of file backup/restore?

8

I think you’re correct. That’s most likely the reason.

What I would like to know then it’s if there’s some configuration, tool or anything I can do to prevent or change this behavior, that it’s not just stopping the synchronization.

Could the backup files be marked so they do not overwrite the client’s until they get overwritten by these?
Or just plainly maintaing the original date at the moment of the backup.

Thanks for the time.

9

Well, for backup purposes, you could use this tool, which will perform a file-level backup of your NC data:

https://restic.readthedocs.io/

and it’s free…!

10

yes, i agree.
if you are not already doing a regular backup of the nc-userdata this is really adviseable. your problem would probably be solved (or nonexistent) if you used a backup-prog that keeps file-metadata intact. you can use really simple stuff like rsync/rsnapshot or more feature-rich (=comlex) solutions like restic or borgbackup.

personally, i keep rather static data (OS) strictly separated from always changing/growing (and valuable) data like userdata.
GOOD LUCK!

11

It should indeed depend on the backup solution and if it preserves modification dates or not. However e.g. when using the hypervisors internal full VM snapshot solution and the Nextcloud data is as well stored on a virtual disk, the timestamps are reverted as well. I am not sure how the Nextcloud clients handle it then when their local sync database does not match the one from the server. But AFAIK also the sync protocol/db is/should be synced with the server so local changes should be recognised as new changes and (re)synced to the server?

So I think details would be fine about which hypervisor you use and how you do backups exactly.

12

While your tools are helpful when it comes to files, they don’t do the job for sql-based data like calendars or contacts etc.
To be honest, I really don’t know why there is no such feature to link existing clients to a new database instance!?
It doesn’t have to be a always on two-way sync but in the event of a “server crash” we can assume the clients usually don’t fail at the same time so that they still have the most recent and up-to-date data.
All that we need is a maintenance operation to tell the new NC server instance (after it has been fixed) to import the clients.
This would be the first logical approach.
A backup will aways have a certain age and therefore be inconsistent with clients, depending on the strategy etc., but with this technique the data is always accurate.
Correct me if I’m wrong!

13

I think about the database related data there is indeed not much that Nextcloud can do. This depends on the sync client (e.g. Thunderbird, DAVx5 etc.) if it stores timestamps about changes at all to be able to compare with server data. Not sure how/if the Cal/CardDAV protocol/implementation handles this. And of course file tags/comments and such is not synced at all so will be always reverted to backup stage. :thinking:

This is actually a good idea. Only issue is that if one made changes e.g. via web UI before the backup that have not yet synced to the client when restoring the backup, you actually don’t want the clients to sync older versions (or remove newly created files) to the server. So timestamps are still the most accurate solution.

So most importantly the server and clients need to have accurate/synced timestamps about changes (of any kind of data that is synced). So if you restore a backup and clients face a timestamp mismatch, the newer versions are always synced. And in case of a file-only/Nextcloud data dir restore (so no database) when re-scanning files, their UNIX timestamps need to be used, which includes that the file backup solution preserves timestamps as well as the backup file system.

14

That isn’t default behavior?
Only changes via gui would be lost. Unless you use a point in time db backup/restore tool.

For those who need a restic script:

Hope you can read jinja templates. :wink:

15

In the “server crashed” scenario, that data would be lost either way (except you can somehow recover data from the database).

16

I have just restored a a Nextcloud installation from backup with timestamps being properly backdated, but the behaviour is still the same: The sync clients will download the (way older, in my case) server version, and mark the local one as conflicted.
I did apply occ maintenance:data-fingerprint and I rescanned the files, and I now wonder whether one of these actions caused the behaviour. In particular, I wonder if one of those two actions causes the file to appear as an entirely “new” file to the sync client, as opposed to a “previously synced but modified” file.