I am using the odrive linux client and it’s working really well.
My question relates to the “backup” option - for which I cannot find documentation.
I am using it under the impression that it allows me to back up arbitrary paths in my filesystem without the need to copy them into the mounted area.
I see with “odrive status” that there are "backups " and what would be useful is to be able to list the backup locations both local-path and remote-path.
Is there a way to do this already.
Edit: I see this is a frequently requested feature so I’ll assume that documentation etc is on the way.
Though it appears to work, are there any caveats to be aware of before it is formally released?
On a separate note; did you ever consider using extended file attributes in Linux to track placeholder files? Just curious!
Hi @sheppard.will,
As you’ve noticed, the CLI has access to an early version of backup. Most of what is unfinished here is UX feedback, but there may also be some deficiencies in exception handling. By and large, though, it should work for the basic need of periodically pushing your data to the cloud.
Extended attribute use was explored in the past for OS X (and to a lesser degree, Windows), but was decided against, at the time. Since Linux support didn’t come until quite a bit later, the existing conventions we were using for the other OSs were carried over (placeholder files). Is there anything, in particular, you had in mind for Linux?
I’ll continue to use as-is. Seems to work well. Hopefully I’m on a list somewhere which will be pinged when the backup feature is formally released.
The xattr was just an idea - I was working on something recently, and it seemed to make sense to use that sort of thing for file meta-data at this level. But the placeholder files work really well. - If you had xattr, I suppose you could name the file anything - but that would just get confusing quickly…
Not sure whether to start another topic but - I make use of network namepsaces to ensure that the odrive agent is in a QOS restricted environment - however, it seems that if I start it in that area I cannot use the odrive commands in other namespaces - so I imagine that locahost might be used for comms? This isn’t an IPC namespace (which also exists).
If there is IPC via networking though, it won’t work if it uses localhost/127.0.0.1 as the agent is in a different space. But it would be nice to be able to communicate with it across network namspaces.
I haven’t played around much with namespaces, but your assumptions are correct. We use a simple socket connection over 127.0.0.1 for communication from the CLI to the Agent process. As you have seen, this will pose a problem when trying to use Agent across network namespaces.