Hi Michael:
Thanks for taking the time to reply to me! If you don't mind, I'll reply in-line.
On 2 Dec 2014 01:02, "Michael Terry" <mike mterry name> wrote:
>
> Hello, thanks for the email! I'm not 100% opposed to the idea. But I fear it may be more complicated than we may initially think. Here are some quick thoughts.
>
After reading through your response, I think you're likely right!
> 1) Did you have any thoughts on how the UI would look? I suppose we could just add a "+" button to the "Backup locations" tab and let users set more... One problem is that user's might reasonably then want different values for other preferences to apply to each location. Like the "how long to keep files in your backup" setting. The complexity could easily grow.
>
Originally, I thought forcing users to have one set of preferences for multiple locations would be reasonable, but that example is a good point. You might want S3 to only keep a limited period of time and keep older backups on an external disk.
I see how the complexity could easily grow. That returns it back to the profile idea, I suppose. Where are the settings stored at the moment? Does that create an obstacle? I want to say I checked once using 'dmesg', but I can't recall now. While I use Linux as my main operating system, the majority of my knowledge is in web development, so I'm that familiar with how the DE actually works.
That said, I'm keen to learn and experiment. I've been meaning to try my hand at Gtk for a while.
In any case, I appreciate your point for wanting to keep the UI as simple as possible.
I'm looking at Deja Dup in Ubuntu 14.04 right now. I think it's important to have the five list options on the left the way they are now. However, maybe "Location 1" could be at the top or bottom of the window followed by a "+" sign. In that way, the layout stays the same as it is now, but adds the ability to have more locations (with their own options).
> 2) It's a real bummer that we wouldn't be able to re-use the efforts of the first backup to help with the second backup. We couldn't directly copy any backup tarballs over because the backup locations might have different contents. And we couldn't re-use duplicity's idea of what's on disk, because it doesn't offer any way to save/re-use that state between runs.
>
It is a bummer that each location would require its own scan and its own actual backup.
That said, that's the reality when someone writes their own script using duplicity too though.
> 3) Meaning we'd just kick off two entire backups back-to-back I guess when the scheduled time hit? If we wanted to stagger them, we could keep separate schedules for them (even if we continued to only expose one schedule option like "weekly", we could have them kick off on different days...). I'm not sure whether staggering is better or worse than just doing them both immediately.
>
I admit that I've been wondering how the scheduling has worked so far. It probably makes sense to do each backup one after another on the same schedule. We'd have to do that for the Daily option anyway, so probably best to do it consistently.
> 4) You ask about the timing of when to do full backups. That we'd get for free. Deja Dup looks at what's in the backup location already and decides if it has been too long since the last full backup.
>
When does it decide that it's been too long though? Is it based on time or the number of backups or something else?
> 5) Reporting errors to the user needs some care, if we're backing up both locations back-to-back. Do we delay errors from backup A until we see how backup B went? Let's say that backup A fails for some reason. I suspect we should still try backup B in that case, but maybe only report an error if we can't back up for a *different* reason -- avoiding complaining about a lack of internet connection twice for example. Other issues would be files that we couldn't back up (permission error or whatever). If they happen to be different between runs, I guess we should merge the lists. But there is a whole set of questions like that. (Or we could report the two separate errors as they happen -- or only back up to location B if A went well?)
>
Very very good questions. I think we'd have to do backups independently (ie independent of the other's success or failure). After all, Backup A might be local, while Backup B might be remote, so some obstacles (like an Internet connection) wouldn't be shared in that case.
But yeah... reporting errors is a tough one. I'm not sure.
> 6) We'd have to make the gsettings schema for the backup location pathless (if that means anything to you, not sure how intimate you are with gsettings).
>
Sadly not really familiar with gsettings yet, so I'm not sure what that means.
> 7) One thought is that we could get most of what you want "for free" for a certain class of users if we simply looked at the mount path instead of the UUID (which as you guessed is what we currently do). The UUID logic was written back before most distros automounted by UUID (how widespread is that now?). My original goal was just to make sure that you never accidentally triggered a backup by plugging in some thumb drive, instead of your backup drive. But if we used mount path, we'd get UUID logic for free nowadays, but we'd also cater to people that had custom fstabs that put both drives in the same mount, right? That's what you originally tried to do, before realizing Deja Dup was using UUIDs? Only really a solution that unblocks the technical users. But a far easier fix at least. Also wouldn't help with any other kind of backup locations (like remote), but I think that's a less common request than "multiple backup drives" which seems to be fairly common -- I guess people take one drive off-site and rotate every now and then.
>
Yeah, using the mount path rather than the UUID would definitely work for me, but would be catering to more technical users using custom fstabs.
Mmm. The mount path idea would only work if we were able to tell if something were actually mounted to the path. Otherwise we could get spurrious errors or filling up a local folder by accident.
I wonder how it would look from a user perspective as well... it might not be obvious to a regular user how to best choose a location.
--
Thanks again for responding. Definitely more complex than I originally thought.
> On 1 December 2014 at 00:04, David Cook <kingandcaptain gmail com> wrote:
>>
>> Hey all!
>>
>> My name is David Cook and I'm new to the Deja Dup list. I'm a systems librarian at Prosentient Systems in Sydney, Australia where I provide support for library technology. I primarily develop in Perl for the open source library management system Koha, but occasionally write in PHP, read Java from the open source digital repository DSpace, and read C from the open source indexing engine Zebra.
>>
>> I've been using Deja Dup to make encrypted backups for my desktop at home for about a year, but I've recently started thinking about doing rotating backups where I'd keep one drive at home throughout the week and the other at the office, then swap once a week.
>>
>> However, I noticed that swapping out the drives at the same mount point wouldn't work as Deja Dup was using something more unique than that (perhaps the UUID, I couldn't tell at a glance).
>>
>> So I started thinking about possibilities for using multiple target locations. Naturally, I found the bug for "Profiles for different target locations" (https://bugs.launchpad.net/deja-dup/+bug/324631). I agree with Michael Terry that having different profiles might be over complicating things. However, I think it makes sense to be able to have the same settings but backup to multiple locations. Michael mentioned that Time Machine doesn't offer profiles, and that might be right, but my friend who uses it mentions that it can back-up to multiple locations (he backs up to a pair of drives). While maintaining separate profiles could make the UI overly complex, specifying more than one location could be very straightforward.
>>
>> That's all I'd want. I'd specify two USB hard drives (or rather their mount points that I specify in /etc/fstab) and then Deja Dup would backup to them if they're available. If one wasn't available (ie it's at the office), it would just do a backup for the drive that is available. Judging from the comments on the bug, it seems like the kind of thing that a lot of people would be interested in.
>>
>> Honestly, I've thought about writing my own scripts to utilize Duplicity, but that leads to a few different problems. So my friend suggested that I fork Deja Dup. Not a bad idea, but I figure... why fork it when I can contribute code back?
>>
>> I suppose the problem might not be as simple as I see it. The timing of when to do full backups is one thing I haven't thought about too much. Is that done weekly or based on a set number of previous incremental updates? I suppose I can go look...
>>
>> In any case... I've taken a look at https://wiki.gnome.org/Apps/DejaDup/GettingInvolved/Coding. I'm willing to set up my environment and learn Vala. I suppose I'm just curious... if I do make this change... would it be something that people would be interested in? Michael, would you be willing to merge it back in?
>>
>> I don't think it would be very complex, and I think it would help Deja Dup to meet the needs of even more people than it already does. Personally, why I am a developer for work, I don't really do much technical stuff at home. I'm just someone who wants to backup his personal data in the event of a robbery (it's already happened once, although fortunately they didn't take my backup drive :P), meteor, or whatever else.
>>
>> Anyway, sorry for the long email. I just wanted to give some context, and note that I am willing to contribute, rather than just saying "please give me this feature".
>>
>> Cheers,
>>
>> -David Cook
>>
>> _______________________________________________
>> deja-dup-list mailing list
>> deja-dup-list gnome org
>> https://mail.gnome.org/mailman/listinfo/deja-dup-list
>>
>