Full backup only copies partial file set

[stevebower]

I've just noticed, though no reason to suspect that the situation has changed, that a 'Full' backup of one of my shares to the ReadyNas backup share only does a partial copy. Tried reconfiguring the backup job (delete target 1st etx) but still the same subset of the contects copied.

Any thoughts?

[StephenB]

What firmware?  Is the source share local to the NAS or remote?  If remote, what machine (windows, ...) is hosting it?

[stevebower]

Hi. I'm on the latest RAIDiator 4.2.28 & the shares are local-local. I've other backup jobs (other shares > backup share) that seem to run fully. Thanks

[StephenB]

I'd expect errors if it can't copy things - have you looked in the detailed logs?

I'd try resetting owners/permissions in the source share ("advanced options" tab for the share).

[stevebower]

I tried that, but it is still only copying the same reduced set of folders. I tried resetting the original drive file owner & permissions to the ReadyNAS group, but that made no difference. No errors shown in the backup log either. Strange!

[StephenB]

You used the "set ownership..." checkbox below and then clicked the apply button?

[stevebower]

Yes. I think the next thing is delete the affected share & re-create.

[stevebower]

Yes. I think the next thing is to delete the affected share and reinstate

[StephenB]

---

@stevebower wrote:
Yes. I think the next thing is to delete the affected share and reinstate

---

You could try deleting the backup job and creating a new one first.

[stevebower]

That's the wierdedst thing - deleted, recreated and copied back the files on the suspect share. Deleted & recreated the backup job. No change. Still what looks like the same subset being backed up, but now when I look in more detail, it seem to be the folders only, no contents??? Think that is what it was doing before

[StephenB]

---

@stevebower wrote:

That's the wierdedst thing - deleted, recreated and copied back the files on the suspect share. Deleted & recreated the backup job. No change. Still what looks like the same subset being backed up, but now when I look in more detail, it seem to be the folders only, no contents??? Think that is what it was doing before

---

Perhaps delete the destination folder?  

[stevebower]

Did all that!

May try partial file sets to see if if a file silently crashing out the backup

[StephenB]

You could also try a manual drag/drop from a PC and see what happens.

If you are ok with ssh, then alternatively copy the folder manually that way.

[stevebower]

Ok I can drag & drop from the share to backup fine, but when I run the backup job & I allow it to delete the orior to running, it creates the same partial folder set as before. Its looking 'consistent', but I can't see the issue

[StephenB]

---

@stevebower wrote:

Ok I can drag & drop from the share to backup fine, but when I run the backup job & I allow it to delete the orior to running, it creates the same partial folder set as before. Its looking 'consistent', but I can't see the issue

---

I'm not seeing it either, it is a puzzle.

You could try changing the source share from local to remote (using the NAS IP or perhaps 127.0.0.1 as the host), and specify the same credentials you are using in the drag-and-drop.  Perhaps use Windows (SMB) as the protocol, since that is what the drag-and-drop used.

[stevebower]

It's very strange as it's only 1 share out of 3 that is affected. All the others back up fine.

[stevebower]

Using the ip & credentials seems to be working. What is the difference between Windows (archive bit) & Windows (Timestamp)?

Cheers

[StephenB]

When doing an incremental backup, Windows (timestamp) uses the modification date on a file to determine if it has changed.  The backup job reads the source files (and metadata) but does not modify the source in any way.

Windows (Archive) backs up a file if the archive bit is set on the source - and when the file is copied, it clears that archive bit.  Note the OS doesn't clear the archive bit on its own, the NAS needs to have permissiion to modify the attribute bits.

Generally speaking the timestamp method is more robust.  For instance if you were making two incremental backups of the same source (to different destinations), then with Archive backups  the first backup would clear all the archive bits - so the second backup would therefore not back up anything.