![]() Mar 10, 2019Hi, I indeed see the same steps on the log, once I deactivate those specific parameters:Ģ019.03.10 10:50:37.149 (UTC-3) 2 1 Processing. Doing it so, will guarantee the files to be replaced will indeed get "archived", but it's not that practical. So, I'm wondering if isn't there something to do about how the program handles the archival procedure of "updated" files? I mean, other than doing the "manual" task of actually "deleting" same named files from source, before copying updated versions of them. There were sometimes when such folder was archived more than once, but with an added timestamp value. ![]() The only thing that got archived was an empty folder, with the original name from the previous version (docs v1.1). The thing is, the external backup disk ended up having the last "1234.txt" file's version, but the original one wasn't archived. I updated the file "1234.txt" at the source's, which was located at the "docs v1.1" folder what I did was replacing such file with a new version, but it still had the same name then I changed the folder's name to "docs v1.2". When to backup: Continuously (real-time).ĭetecting changes: Use destination snapshot.ĭeleting: Archive backup copies. What to backup: everything with some exceptions (default rules). I think the issue I faced wasn't related to an additional backup job's execution, but to a "by design" program's behavior.īackup from: "E:\" (SOURCE, fixed int. Mar 04, 2019After doing some new tests, I realized about some misconceptions on my part. I'm wondering, isn't there any kind of feature which avoid the aforementioned situation to happen? Other than myself being aware of what drive I have hooked up at a specific moment, before doing changes to the source or rather changing one of the backup jobs to not get "real time" but delayed/manual executions. Under such circumstance, after I made some changes to the source, they were propagated by the backup job which isn't doing "archival" copies, to its (already connected) respective drive this led to the updated files being just deleted, which is expected, but once I connected the second destination drive (which is doing archival copies), the related job simply didn't archived any of the original files, since by then they were already deleted by the previous job. ![]() The thing is, the drives' presence isn't always the same sometimes only one of them is connected, others both. I have both jobs configured to be executed "continuously", so whatever drive is already connected/present at the time of a change, gets the job done. Mar 01, 2019Hello, I never thought of this situation before, but it just happened to me.īasically, I have one common source and two destinations, they are handled by two almost identical backup jobs, being only their paths and the "backup copies" related option the differences. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |