Windows 10: FileHistory causes slow access of NAS when accessing through FQDN.

When FileHistory starts doing next incremental backup or is triggered manually, It almost locks down access to NAS:
* When attempting to browse NAS with file explorer, each refresh of directory takes 5-8secs. minutes if directory has 100+ files

* And this slowdown causes progress of FileHistory to slowdown/lockup on it self, and thus it never finishes.

* By canceling backup process, performance issues disappear.
* For years now I used FileHistory and never had such issues under various system loads. my only suspicion is that random windows update caused these problems, as there were no other major changes in the system


The weird part in all of this is: while FileHistory has things locked up. When I manually access NAS using FQDN \\hostname\... it will be slow/unusable as described above. But when going into the same server through IP \\x.x.x.x\..., it works/responds with no issues.

p.s. Path provided in FileHistory configuration is also through FQDN.


What could be causing this?

:)

 

can't access older FileHistory

I can't access FileHistory on an older, filled external drive.

How do I access the edb, xml, and data files since if I start FileHistory on that drive

it starts a new FileHistory also telling me the drive is full.

Is there a program that let's me access my older FileHistory?

It is Windows 10 I believe.

Thanks,

Larry

 

Bug > FileHistory/Credential Manager

Hi,

I don't know where to report this so please guide me.

I use FileHistory to back up all my Windows 10 PCs. Target backup location is a Synology NAS.

FileHistory uses the Credential Manager to log into the NAS and store the backup files. To me that's a huge problem and therefor a serious bug.

If I have to store credentials in Credential Manager for FileHistory to be able to store the backup everyone can access that backup data.

I should not be difficult for ransomeware to ask the Crendential Manager to browse the backup location and then encrypt it. It's pretty ironic that this is a valid scenario - you would think your FileHistory backup is where you restore all data from when it
has been encrypted - but that's not the case when the entire backup is encrypted.

I suggest that FileHistory uses it's own password vault instead of Windows Credential Manager. It's a huge flaw that the Credential Manager is being used for backup purpose and it defeats the purpose of having a secured backup when everyone can access the
backup files. The goal must be to only grant the backup client access to the backup location.

// peter

 

Recover access database

Looks like you will need to rebuild the whole thing but at least you have the data still, right?
EDIT: Wait did you try this?

Convert a database to the Access 2007 file format

http://office.microsoft.com/en-us/a...-the-access-2007-file-format-HA010048406.aspx


You cannot convert a replicated database to the Office Access 2007 file format. However, you can use Access 2007 to create a replica of a database that is formatted in either the Access 2000 or the Access 2002 - 2003 file format.


More copy and paste:
[paste:font size="5"]Convert an Access 97 database, Convert an Access 95 database, or Convert an Access 2.0 database.

• Click the Microsoft Office Button
  
  , point to Save As, and then, under Save the database in another format, click the file format to which you want to convert.

• If any database objects are open when you use the Save Database As command, Access prompts you to close them prior to creating the copy. Click Yes to make Access close the objects, or click No to cancel the entire process. If needed, Access will also prompt you to save any changes.

• In the Save As dialog box, type a file name in the File name box, and then click Save.

Access creates the copy of the database, and then opens the copy. Access automatically closes the original database.

Here is a short and sweet version: http://www.ehow.com/how_7339817_convert-2003-database-access-2007.html