what to do with sync.ffs_db after an image disk restore
- Posts: 3
- Joined: 4 Nov 2021
I restored the disk C of a computer using an image saved months ago, so now I have to manually update some system files that I recovered from my backup with freefilesync, which I use with the "detect moved files" option enabled. I don't know what to do with the sync.ffs_db files, should I leave the old ones from the restored image or should I replace them with the latest ones I find in the various folders of the backup? Thank you very very much
-
- Site Admin
- Posts: 7506
- Joined: 9 Dec 2007
If you've run a FFS sync after you created the backup, and now you've restored the backup, FFS will not regognize the ffs_db files anymore and behave as if you were syncing this folder pair for the first time. In other words: they are not used.
If you have not run a sync after the backup creation, FFS will regonize and use the ffs_db files as usual.
If you have not run a sync after the backup creation, FFS will regonize and use the ffs_db files as usual.
-
- Posts: 4867
- Joined: 11 Jun 2019
The db file in the backup copy can stay there, as db files are specific to their location. If I understand correctly, you have a db file on the C drive that is a few months old now, so you are concerned that it will cause issues being "out of date"? If so, you don't have to do anything, just run the sync again. Since that db file is specific to the location, it's best to have that original one in there.
- Posts: 3
- Joined: 4 Nov 2021
hi xCSxXenon, glad you and Zenju answered me! I messed up something...
When you write that they are location specific, do you mean that 1 - the db files in the source dirs (in C) are different from those in the identical target dirs (in the external disk) because they have different functions, or 2 - that they are identical (because they are backups) and are specific obviously for the different C dirs?
When I restored the C disk using a Reflect image, obviously I found myself with old db files from the time of the image and - without thinking that they could have had different functions from those of the destination dirs in the external disk created by ffsync - when I updated the old restored files with those of the last ffsync backup I overwrote also the old db files.
Now - after some backups - checking the db files, I see they all have been updated at least to the first backup made after the restore, with identical date and size between source and destination, which makes me think that hypothesis 2 is right. In any case I don't know if I did the right thing to overwrite the old db files of the restored image with the backup ones.
One strange thing is that the db file on the D disk (which I didn't restore) dates back to the first installation of ffsync, two years ago, while the one on the external disk is updated to today and half the size! I really don't understand why they are not identical as for disk C.
I'm wondering if it is better to delete all the db files and restart.
When you write that they are location specific, do you mean that 1 - the db files in the source dirs (in C) are different from those in the identical target dirs (in the external disk) because they have different functions, or 2 - that they are identical (because they are backups) and are specific obviously for the different C dirs?
When I restored the C disk using a Reflect image, obviously I found myself with old db files from the time of the image and - without thinking that they could have had different functions from those of the destination dirs in the external disk created by ffsync - when I updated the old restored files with those of the last ffsync backup I overwrote also the old db files.
Now - after some backups - checking the db files, I see they all have been updated at least to the first backup made after the restore, with identical date and size between source and destination, which makes me think that hypothesis 2 is right. In any case I don't know if I did the right thing to overwrite the old db files of the restored image with the backup ones.
One strange thing is that the db file on the D disk (which I didn't restore) dates back to the first installation of ffsync, two years ago, while the one on the external disk is updated to today and half the size! I really don't understand why they are not identical as for disk C.
I'm wondering if it is better to delete all the db files and restart.
-
- Posts: 4867
- Joined: 11 Jun 2019
FFS doesn't copy, move, or overwrite its db files. They only pertain to where they exist, so the one on your internal drive is not the same as the one in your backup. They contain a "snapshot" of the state of the directory they are in so you don't have to delete and copy files when they are simply moved or renamed, saving time. The only way a db file could get transferred from a source to destination is if you do it manually, so you are fine if you didn't do that. You could delete them, it won't hurt anything other than waste some time if you moved or renamed files before your next sync.
Basically, you can restore from an image that was made months ago, simply open FFS to run a backup, and nothing bad will happen from "old" db files. They don't store anything relevant to the data itself. It is so FFS can see "Oh, this new file x in the source is actually the same as file y in the destination but just got moved to a different folder. Instead of deleting y and copying x, which may be a large file, just move y in the destination to the new location".
The db is just keeping record of where files are and what they are named.
Basically, you can restore from an image that was made months ago, simply open FFS to run a backup, and nothing bad will happen from "old" db files. They don't store anything relevant to the data itself. It is so FFS can see "Oh, this new file x in the source is actually the same as file y in the destination but just got moved to a different folder. Instead of deleting y and copying x, which may be a large file, just move y in the destination to the new location".
The db is just keeping record of where files are and what they are named.
- Posts: 3
- Joined: 4 Nov 2021
Perfect, thankyou xCSxXenon