How to identify if a file has not been backed up in Windows 10
We have a Cobian backup apps that is configured to backup 'increment' form. However, after upgrading our computers to Windows 10, for some reason, it detects that the files programmed to backup, reads them ALL as "not backed"; thus, running a backup for over 30gb of data.
We figure that the best bet to have the apps running again as increment is:
We came to this conclusion based on the properties of the files in this periodic backup routine we have setup (see below)
Please advice what Windows program we can use to find the files modified after 12/8/2015 and what windows program we can use to change
We figure that the best bet to have the apps running again as increment is:
Search all files in backup area for files last modified after the correct backup performed which was 12/8/2015
Change the configuration of those files identified as modified after 12/8/2015 to NOT-BACKED-UP (don't know the correct technical wording to Not0Backed-Up-Status)
Run the Cobian apps again so it can backup all modified after 12/8/2015
We came to this conclusion based on the properties of the files in this periodic backup routine we have setup (see below)
Please advice what Windows program we can use to find the files modified after 12/8/2015 and what windows program we can use to change
Qlemo
Sounds as if the Archive file attribute as been set on all files. Sounds strange, though.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK, so there is an attribute we can change!!! Thanx!!
To understand it, in line '$_.Attributes -like '*Archive*' -and $_.LastWriteTime -lt $BackupDate } ', the '$_.LastWriteTime' is the "condition" where it says if FILE-CHANGE-DATE is greater than '$BackupDate'?
Also, running this will also modified the sub-folders?
To understand it, in line '$_.Attributes -like '*Archive*' -and $_.LastWriteTime -lt $BackupDate } ', the '$_.LastWriteTime' is the "condition" where it says if FILE-CHANGE-DATE is greater than '$BackupDate'?
Also, running this will also modified the sub-folders?
The logic is reversed. The archive bit is set whenever a file gets modified (or created). It is not "has been archived" but "needs to get archived", where "archived" means "backed up".
So the condition will check for the archive bit set (= will get backed up), but being modified prior to the timestamp of "2015-12-08 22:00" (08-Dec-2015 10:00pm). I've assumed an arbitrary time, change as needed.
-lt stands for "less than", and in time references means "before".
get-childitem -recurse will go thru all subfolders and files starting at the path provided. -recurse is saying that.
So the condition will check for the archive bit set (= will get backed up), but being modified prior to the timestamp of "2015-12-08 22:00" (08-Dec-2015 10:00pm). I've assumed an arbitrary time, change as needed.
-lt stands for "less than", and in time references means "before".
get-childitem -recurse will go thru all subfolders and files starting at the path provided. -recurse is saying that.
ASKER
Understood.
Can we use that same script or maybe changed it to only display, not change the attribute?
(we want to see how many files has been modified after 1218/2015)
Can we use that same script or maybe changed it to only display, not change the attribute?
(we want to see how many files has been modified after 1218/2015)
Replace line 7 with
$_
That will just push the file object to the pipeline, and since we are not doing anything with it, display it.
$_
That will just push the file object to the pipeline, and since we are not doing anything with it, display it.
ASKER
Line 7 says '$_.Attributes += 'Archive', where should we place '$_'?
That's all good, but first: is your cobian software aware of the archive bit - are you sure? Some softwares use their own hashing methods to determine if a file has changed and needs to be backed up.
Also: you say it does not work the way you like it after upgrading to win10. So when was the last backup done? Before the backup to 10? Then 30 GBs of increment would be perfectly normal.
Lastly: what does cobian support say and is the software known to be win10 compatible?
Also: you say it does not work the way you like it after upgrading to win10. So when was the last backup done? Before the backup to 10? Then 30 GBs of increment would be perfectly normal.
Lastly: what does cobian support say and is the software known to be win10 compatible?
ASKER
is your cobian software aware of the archive bit - are you sure?
So when was the last backup done? Before the backup to 10?
what does cobian support say and is the software known to be win10 compatible?
Yes, the cobain software is aware of the archive bit (we've been in using the apps for some years).
So when was the last backup done? Before the backup to 10?
On December 8, 2015 and the before upgrading to w10
what does cobian support say and is the software known to be win10 compatible?
We did go into Cobain site prior upgrade and there is no mention of w10 compatibility, but lots a forums has said works with no problem; so we gave it a go.
ASKER
Ok, we think we got it; how to display all files that are with the ARCHIVE active and before 12/8/2015 (had to take a short course on powershell but came in good time):
dir -recurse | ? { $_.Attributes -like '*Archive*' -and $_.LastWriteTime -lt $BackupDate}
so our question on ID: 41389183 can be omitted.
Now test the changing of attribute
dir -recurse | ? { $_.Attributes -like '*Archive*' -and $_.LastWriteTime -lt $BackupDate}
so our question on ID: 41389183 can be omitted.
Now test the changing of attribute
ASKER
We tested the script on a test folder and it changed the attribute to every file before 12/8/2015!
(note: the $BackupDate value changed it to 12/8/2015 23:59)
Thanx!
(note: the $BackupDate value changed it to 12/8/2015 23:59)
Thanx!