We are running server 2.1.18 on Centos 6.x and using Windows client 1.4.11 on Win 7. I’ve noticed that when a full is run, that all folders are being timestamped with the timestamp of the full backup. At first I thought these folders might have been opened which would change the last modified date, but I know for certain that they were not. I then noticed that certain files (.rtf files for example perhaps other) seem to also get timestamped with the timestamp of when the full runs. None of these file have been opened or touched for months. Can anyone explain why this might happen? Perhaps something in UrBackup that triggers changing the last modified date or some issue in Windows that causes directory and file last modified dates to be changed? Maybe the simple act of opening a folder to back it up causes the problem. It’s causing a real problem as we have users who search by date. I would expect that UrBackup would not modify any dates on folders or files.
So what’s happening here is that when UrBackup runs it’s creating a folder with the machine name like: ACADIA/170228-0815. That’s fine, no problem, expected behavior. However, when it backs up Windows folders, for example, c:\users, it timestamps that folder with the date of the backup. This is not too much of a problem (although it seems to do this on all directories and not those have been modified and I don’t understand why those are timestamped), however, we’re seeing in some cases the files within a folder have their timestamp set to the timestamp when the the backup was run even if they have not been added, deleted or modified. Other files within that same directory retain the timestamp. That’s a problem as many or users will sort documents based on timestamp. Another thing we’ve noticed is that if we download a zip file of a directory (using the UrBackup functionality) we sometimes see that the dates on the directories and files are set to some future year like 2097.
I’m gonna go with a bug; since a Windows Server on 2.1.15 does not seem to be having this issue.
Whether it’s a bug about UrBackup or a different service - like your time and date, I don’t know. @uroni anything on this?
Also, [quote=“pjablonski, post:1, topic:3113”]
We are running server 2.1.18 on Centos 6.x and using Windows client 1.4.11 on Win 7.
[/quote]
Server 2.1.18, I’ll assume it’s the one from SourceForge? The newest one on the forums is 2.1.17.
So, there are two servers (2.1.19 - CentOS 7 | 2.1.18 - CentOS 6) with (2.0.29 - Windows | 1.4.11 - Windows) respectively.
Both of which have time stamp issues on BOTH server and client side (from what I have read so far).
2.X clients keep time-stamps; these two clients are on separate servers both running CentOS…
It sounds almost like a coding, installation, or handling error. Like attempting to grab the modified date and replacing the value with the backup date, for at least the 2.0.X clients - since 1.X does not support the date modified; or maybe it follows the legacy rules as long as there is at least one legacy client on the server?
But that could also just be a huge speculation; I don’t know if you can update that 1.4.11 client or not, but you could try updating your 2.X client(s) and remove any 1.X client(s) from the server and see if the error persists?
thanks for being persistent in helping me sort this out.
The two servers are physically separated and unrelated and have different clients associated with them. The timestamp issue only is on the server side in both cases. When a backup runs on a Windows machine that has either a 1.4.x client or 2.x client, when we look at the timestamps on the backups made from the Windows machines on the Centos UrBackup server (actually log in to the server and look at the timestamps on the directories and files backed up) we see the backed up directories timestamped with the timestamp of when the backup ran. Some files in those directories are also timestamped with the backup time, most files are not.
Updating the 1.4.11 Windows clients will be tricky as we have about 100 machines with that client backing up to the 2.1.18 Centos 6 server. What I may be able to do is approach the second request where we update our 2.029 Windows client and delete the backed up clients on the server side (running the 2.1.19 server) and see what happens. That will take some time, but perhaps is the first step in teasing this apart.
In an effort to get a handle on this (and avoid any possible inconsistencies that may exist on the other two setups I’ve talked about) I went ahead and set up a new Centos 7.3 server with the latest UrBackup server 2.1.19 compiled from source (https://hndl.urbackup.org/Server/2.1.19/urbackup-server-2.1.19.tar.gz). I then set up the latest Windows client 2.1.14 on a Windows 10 machine. I then started a full backup. While the backup is still running, right now when I look at the backed up directories and files on the server I see that they all have today’s date and a time of when the file was written to the server. Unless UrBackup writes timestamps to each file after the full backup is complete, I would say that there’s something wrong here with regard to timestamps. Please advise as to how to further troubleshoot. Thanks.
So there is good news to report. After the backup is complete, it looks like all the timestamps on directories and files are preserved (that is, correct). So what I can conclude is that somewhere there is a combination of 1.4x client backups with a 2.x server upgraded from 1.4.x that will result in timestamp issues. Similarly, running a 2.x client with a server that was upgraded from 1.4 to 2.x displays the same behavior. It looks like the cleanest path is to start fresh with 2.x clients and a 2.x server. Thoughts?