QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Mike M
Forum Index » Profile for Mike M » Messages posted by Mike M
Author Message
Okay, when I get upload request I will do.

In the meantime, just now I tried creating a new archive and capture strategy, with the assistant, on a different disk. You know how the last thing the assistant asks is whether you want to do a first capture right away? I declined that, and instead completed the assistant, then went to the action list, selected the capture action, and started a capture. So far it has run for 30 minutes with no error, so that's an improvement.

I tried to create a new archive, and got "lost connection with process" during the first capture. Repeated this several times, rebooting between times, and continued to get trouble.

I sent a bug report a week ago but haven't heard back. More details are in the report.

Thanks, working on it now. The repair has been going on for an hour and has "examined" about 1/4 of my data. I didn't realize it would take so long; I need to shut down my computer in a couple hours.

This is the second time my archive has needed repair. Any advice about how to minimize these occurrences? It is possible that my hard drive was unplugged without ejecting it--maybe that is what damaged the archive. That is only speculation, however. I don't recall seeing any messages to that effect from OS X.

First I got an error that the archive needed repair. Then for a couple of days I've been getting errors "Lost Connection With Process."

Using QRecall 2.0.7 on Sierra.
I see where the checkpoint model, or rather my idea that merging layers can be reframed as "deleting checkpoints," gets more complicated. Very interesting, and I think it was a useful thought exercise for me to write that out. Now I am in a better position to take in the information you gave at the very end. I will look at that tonight or tomorrow.

Also, sometimes when I'm dealing with a complicated concept, I need to make a diagram myself. If I find the way of arranging the diagram that makes it most appealing and clear to me, then I have learned something.

I am a math tutor and that's a trick I use sometimes: ask the student to find their own way of writing out and expressing the concept they just learned. Or ask them to pretend they are teaching it to me.

I'm having some trouble understanding the behavior of QRecall. I suspect that the notion of "layers" is obfuscating things for me. Let me propose another concept, which I'll call "checkpoints."

I am running into certain questions, like trying to think about whether certain old versions, or whether an old deleted file, is still in the archive. I'd like some deleted files in certain directories to stick around a while, and others to go away quickly. I'm trying to understand how to answer these questions.

Let me propose the concept of checkpoint. If a checkpoint at time T exists in the archive, it means that the "file state" of the captured items at time T can be reconstructed.

Here is how that is different from a layer. Your documentations describes layers as containing (1) files, (2) deltas from previous layers, and/or (3) some indication that a file has been deleted.

Your layers also have numbers rather than time tags--at least that's how you always describe it in the documentation.

When layers are merged, you renumber them.

To think, then, about whether a file can be reconstructed at time T, first I have to wonder if layers have time tags. I have not gotten deeply into QRecall so I'm not sure -- however, I do know that your examples use layer numbers instead of time tags, and so it's an extra step of thinking to go from the example to the idea of a time tag. Also the numbers keep changing. It seems simpler to consider that a time tag *never* changes.

So let's say a layer is time tagged as T. Then I have to consider which of the three items mentioned above (1, 2, and 3) exist in this layer. I also have to consider what exist in earlier layers. Then I have to wrap my head around the algorithm used to reconstruct a file.

So what about the idea of checkpoints? Well, let's say there's a checkpoint at time T. I can then know, simply, that enough information is in the archive to recreate the state of all captured items at time T.

I don't have to concern myself with how that data is represented. It might be deltas, it might need to refer to prior layers, it might look at other markers in the layer... but I don't need to know any of that stuff.

Now let's consider the concept of "merging layers." This gives me a headache. I think it's actually a quite involved algorithm, and your examples have lots of parts in their diagrams.

What if, instead, we say that QRecall "deletes checkpoints"? No longer is there the concept of "merging." Instead, I can think about a "checkpoint deletion" as removing information from the archive ... and it's easy to think about that. The information lost, simply, is the state of the file system at the deleted checkpoints.

I don't have to care whether this is done via merging layers or any other algorithm. I also don't get a headache trying to think about the behavior of the system.

Now let's say that I ask myself, "hmm, does a certain deleted file exist in the archive?" The answer is, "it does if it existed at one or more checkpoints that are left in the archive." Now let's say I want to ensure that QRecall behaves in my desired manner, that is, it keeps enough useful old data, but also doesn't get too large. Well I just think about what checkpoints exist and what is the algorithm that determines the oldest possible checkpoint.

One statement in the documentation about the rolling merge is, "all layers older than <something> are merged into a single layer." This is another statement that gives me a headache. I have a question at this point, if you could answer it. Can you put that in terms of checkpoints? Does this mean that any checkpoint older than the oldest time frame in the rolling merge is deleted?

One last comment about rolling merges. If I reframe the behavior in terms of checkpoints, here is how I envision it. Let's say I have a daily capture. This creates checkpoints at times T_1, T_2, T_3, ... etc, where these times are 24 hours apart. Imagine that we have a timeline, and that when QRecall creates a checkpoint, it's like dropping a bread crumb onto the timeline. Let's get whimsical and imagine a path in the forest. Hansel and Gretel drop a breadcrumb every 24 hours.

Now what is a rolling merge? It's basically a bird that comes along and gobbles up some of the crumbs. Let's say I keep 28 daily layers. That means the bird ignores the most recent 28 checkpoints. But the bird looks at checkpoints older than that, and starts gobbling them up. If I have weekly layers, then the bird gobbles up 6 out of every 7 checkpoints, leaving some bread crumbs a week apart.

You could think of it like this. Six days of the week, the bird gobbles up the bread crumb that is **29** (28 + 1) days old. But one day of the week, he leaves it alone.

It's a little different from the perspective of the internals of QRecall. My way of expressing it is "a checkpoint disappears," which I find to be clear. But you, as the programmer of QRecall, have to think about what that means in terms of removing and merging state in the archive. My primary point here is that QRecall's algorithm should be decoupled from the user's thought process.

Now let me stop here and ask, is this actually an accurate way of thinking about it?

Is there a way to purge old deleted data, either manually or automatically? I have a folder on my computer X. If I lose data in X, I'd like to have the following capabilities:

(1) restore any data that was currently present at the time of the loss of X

(2) restore data that was accidentally deleted from X by retaining deleted data for a few months

#1 is a basic backup/restore function, as you would expect. #2 means I want to keep deleted data, as QRecall normally does, but I don't want to keep it more than, say, three months.

Got it. Very nice to use once I understood it.
I seem to have somehow lost or blown away changes I expected to be in a particular file. I right-clicked on it and selected "reveal in archive." I see the file name and I see four layers listed above it, with numbers like 7, 13, 21, etc. I suppose those are the layers in which changes were captured. I want to recall all of these versions. I am not clear how to select a particular layer. I clicked on each layer and highlighted them, and I looked at the recalled files, but I don't see the changes I'm looking for. I'm not clear if this did what I want; is highlighting a layer before the recall the right thing to do? It's hard for me to check differences between the recalled versions, so I want to start by making sure I'm doing it right.

I want to back up part of external drive A to external drive B. Neither is necessarily always connected.

I am already backing up my main drive to B, and QRecall created a strategy for me for the case that the archive is not always available. I think that it selected "Hold while archive not present."

What I would like to do is something similar, but also hold when drive A is not connected. I see there is an option called "hold when no items" or something like that. Is that what I would use?

Is the wisdom of capturing every change related to the size of the item? For instance, is capturing "Home" on every change not wise in part because a capture of Home, which is a very large tree for me, would be a lot of work for QRecall that would be occurring non-stop?

What about capturing every change in a small folder even when that data changes every few minutes? The capture would be triggered frequently, but perhaps would run quickly.

But no matter the answer, keeping hourly or daily captures is fine 99% of the time, if you consider losing a day of work to be a minor event. (It's minor for me--I don't do anything "mission critical.")

I also keep a lot of my files in my Dropbox folder so that provides another layer of backup. Dropbox keeps old versions too and it may even keep every version of files that change frequently if they are small enough to upload quickly.

By the way, I just switched from Windows (after 25 years) to Mac, and although I do look forward to the benefits of Macs (and I always thought Apple makes more beautifully designed products) it has not been an easy adjustment, and in many cases I have not yet found equivalent software to what I was using on Windows. But I can complement QRecall -- far better than any backup software I found on Windows, less expensive to boot. It meets my backup needs exactly, and as far as I can tell, it does it simply by being a good design to address the fundamental domain.
Okay, so everything looks pretty good. I did the following:

- installed OS X on a 2 TB WD Passport drive so I will have it ready to go in the event a recovery is needed

- I used the "assistant" to set up a daily capture of my entire volume.

- I then used the item context menu to exclude the Downloads directory

At this point there is only one more thing I would like to do:

I want to capture a couple of directories, where I do 90% of my work, on an hourly basis.

It looks like all I have to do is add an hourly capture action on those folders, let's say at 30 minutes after each hour. The other actions that the "assistant" set up (rolling merge, compact) will probably work just fine. It looks like the rolling merge will keep the hourly captures for 5 days, then convert them to day layers.

Does that sound okay?

I've been studying the QRecall documentation and I can't figure out if it can do something.

First I plan to create an archive of my main drive. That seems like a great advantage to be able to restore the main volume when disaster strikes.

But QRecall will also be useful for holding old versions of certain files. Most of my work is actually on a small set of my files, and I might like to create an action capturing those directories more often (capture them to the same archive for the whole volume, is my understanding of how to do it).

I have another situation. I frequently download large data files into the Downloads directory, and within a week, delete them. I have no need to save them longer than that. But if they are captured, then they may stick around in the archive for a long time, depending on how frequently I merge layers.

I wanted to see if there's a way to merge only portions of layers, say only the files in the Downloads directory. I don't see such a thing in the docs. Of course, I bet that such an action doesn't make logical sense--it might violate some consistency rule in the archive. Just guessing.

So that leaves the delete option. I see that I can manually delete some of these files. Is there a way to create a Delete action that would run on a schedule and delete stuff in Downloads?


I see! I see that's part of the flexibility of QRecall, the ability to set up different capture actions on a different schedule.

I will read the documentation and if I have any further questions, get back to you.
Thanks very much. I have another question which is not specifically a QRecall question, but I thought someone here might have some advice.

I have a 2TB WD Passport drive. This is only a few months old. I recently purchased DriveDx in order to read the SMART data, which shows one condition of concern, which is that there are 3 bad sectors waiting to be remapped. DriveDx pops up a little message saying that a drive with even one bad section *waiting* to be remapped (I think the "waiting" concept if part of the issue) is 16 times more likely to fail within a year.

This 2 TB drive would be handy for holding two QRecall archives (one for the whole drive, one for my home directory), but I don't know if this condition is something to be concerned about.

One person told me that any large drive is going to have bad sectors, and go ahead and use it, just keeping an eye on the SMART data. But that DriveDx message is worrying.

Forum Index » Profile for Mike M » Messages posted by Mike M
Go to:   
Powered by JForum 2.1.8 © JForum Team