Hardlinks when moving files inside nextcloud

Hello,
I am moving nextcloud folder from one position to another one using web interface. On the linux server at the end they are on the same filesystem. So in my mind the operation should be a move operation on the linux fs (operation which keeps the same inode number for the file) and a change in the mariadb to make nextcloud point to the proper place. Which means immediate change.

I have also clients synced, and in the client I see a lot of synchronization activity, very long, and in the activity tab of nextcloud web interface I see many “you changed file1.pdf”.

So it seems that hard links are not used on the server, or am I wrong? I am asking because I have a backup strategy based on hardlinks, and if files are copied it is a big mess…

thanks

Sounds like playing with fire to me. Nextcloud is very sensitive to changes to the files. I would suggest just officially changing the data folder instead.

It is more the question: is the inode of the “move” (php command) preserved? Check the inode before and after move. Search the program code. Maybe it is not possible with php.

1 Like

Ok I did all the tests:
Web interface: renaming a file or moving the file in a different location, the inode is preserved on the server
Nextcloud client on Mac 3.5.4: renaming a file or moving the file in a different location, the inode is preserved on the server

From a practical point of view this means that managing incremental backups with hard links is possible, and no space is wasted during re-organization of files on the filesystem.

You ought to use another backup tool instead. Rsync or even better, snapshots using Btrfs, ZFS or LVM.

WOW and it works also moving/renaming files in external folder, when they are “local external folder” i.e. unix filesystem folder outside the nextcloud data directory.

Amazing.

@Gatak thanks, I will have a look to btrfs. Unfortunately my filesystem is now defined as ext4, and I don’t want to reformat.

I honestly would rather recommend borgbackup or restic for backups… Snapshots are no real backup imo…

1 Like

Thank you so much for the information. I will have a look to them. At present I am doing:

  • daily hardlink snapshots with rsync, mantaining a full history of the tree day by day (covering from accidental deletions by user)

  • tar archive on separate devices every 15 days (to have a full backup on different computer)

  • mirror the nextcloud tree on a similar linux machine, to have a quick recover solution in case of hardware fault of the nextcloud server. In this latter case, I don’t have yet a software able to perform this activity, I will search.

Additional information: even if you move/rename files from nextcloud (web interface) moving from the main tree to external storage and vice-versa, the inode remain the same as long as the main tree and the external storage are on the same filesystem.

For example if we have /Data/nextcloud and /Data/external_storage

True,snapshots help recovery if you delete or overwrite files by mistake. But most importantly they allow for easy backup without having to worry about files that currently being written too or locked by applications (mysql) etc. You run the backup tool from a snapshot instead of luce data.

Hard links are dangerous as snapshots as the files could be altered if the hard linked file is updated.

Yes, for snapshot using hard link I use
rsync --link-dest
which instructs rsync to copy the file if it has changed in reference to the old version. If it hasn’t, then the hard link is created instead of the copy.

I use rdiff-backup, which is built on top of rsync, efficient (incremental backups) and simple to use.

1 Like

thanks I will have a look to all these tools

Wow rdiff-backup is amazing. Very simple, short usage manual, and I can replicate the differential backups over the network to different machines. Only a little longer than hardlinking with rsync to extract files deleteb by error but more flexible.

Thanks

Proposed this change long time ago:

Works fine with NC. Currently use rdfind -makehardlinks true as workaround or this script to make it more smart:

You’re welcome!