Déjà Dup Backup Tool

[Feature] Detailed scheduling

Reported by Michael Terry on 2009-11-09
330
This bug affects 67 people
Affects Status Importance Assigned to Milestone
Déjà Dup
Wishlist
Unassigned

Bug Description

[From user Sergey Sedov]

I think that It would be very nice to have the ability to set schedule for hours.

For example, I would like to run the backup at 8.00 and 20.00.

Michael Terry (mterry) on 2009-11-09
Changed in deja-dup:
importance: Undecided → Wishlist
status: New → Confirmed
crjackson (crjackson) wrote :

Adding my name to the list for needing this feature.

Thanks for a great backup application.

-crjackson

XuMuK (xumuk37) wrote :

would be useful. Add myself too.

Daniel-gross (daniel-gross) wrote :

Since i am currently writing a large document, an important feature for me would be to back up every couple of minutes.

cement_head (andor-udel) wrote :

Hello,

  I would like to at least (even by CLI) be able to schedule the day (of the week) that the backup occurs.

- CH

Gabor Halaszvari (g-halaszvari) wrote :

It would be a good feature also to be able to turn off or abort scheduled backups when a notebook is running on battery

Jogarem (jogi) wrote :

yes scheduling is a nice idea because otherwise when you are busy at normal office time you will stuck..

Michael Terry (mterry) on 2011-06-22
tags: added: needs-design

I'd like to third the comments on this page. I used to use RSBack and set my backups to every four hours (mostly because my friends laughed at me if I set them any closer together). The overhead for incremental backups was next-to-nothing, but it did save me a few times with some work. So I'd like both to be able to specific roughly when or roughly how far apart the backups need to occur.

It would be nice to have some kind of way of knowing whether the backup succeeded in such a case: currently I have no idea if the backup succeeded or not. On a notebook that comes and goes from the internet it would be nice to know when it was going to try and whether it succeeded.

memilanuk (memilanuk) wrote :

Another +1 for optional time scheduling - both what day of week for weekly backups, and what time of day, etc.

Niklas Park (niklas-park) wrote :

Just another hearty +1. Yes please.

Hacktor (hacktor) wrote :

+1 for changeable scheduler

Janne Moren (jan-moren-gmail) wrote :

I only have my backup NAS available when I am at home, and I'm only logged in/awake certain times. Without a way to set this I may not ever be able to get a backup done automatically.

Michael Terry (mterry) wrote :

Just a note, GNOME is planning support for network zones like "Home" and "Office" [1]. A simple dropbox for which zone to back up in might be a good way to add support for some of the listed use cases without making an interface that has to support all sorts of time controls.

[1] https://live.gnome.org/ThreePointThree/Features/NetworkZones

I don't see how network zones can have any effect on scheduling, since the network and scheduling are completely unrelated.

My use case involves not tying up limited netbook resources at times when I know I'll need full access to my machine--such as when I'm teaching.

The current scheduling options look like this:

How often to back up |_________v|
        Keep backups |_________v|

It wouldn't complicate things too much to add a "Manually specified" option to the frequency combobox. When "manual" is chosen, the following interface could appear (_*_ indicates a text box, |_*_|v| indicates a dropdown box, and [ ] indicates a checkbox):

Backup every _1_ |_Days_|v| # Other options: Minutes, Hours, Weeks
[ ] At [timebox] # Grayed out if the interval doesn't make
                             # sense for this option to be available.
                             # Optionally, there could be a button
                             # to add additional timeboxes, but one
                             # should be sufficient for most cases.

I think this interface would address most use cases and wouldn't add significant complexity to the interface.

Michael Terry (mterry) wrote :

Scott, I mentioned network zones because I was thinking of a setting on the "Schedule" tab that would look like:
Only back up when in network zone: [ drop down box of network zones ]

That way, use cases for detailed scheduling that are based on statements like "I only want to backup when I'm at work" or "only when I'm at home" could be addressed.

In your case, maybe that would fix the issue with teaching too? i.e. you can avoid backing up when in the "School" zone.

That wouldn't address my use case, because the machine in question spends nearly all of its time at the school (I normally leave it there when I go home). Furthermore, there are plenty of times when it's OK to back up even when it's at school, because I only use it in certain classes. Forbidding backups in the school zone would result in perhaps monthly backups instead of daily backups.

In fact, my use case could also be addressed with a blacklist approach, where backups at certain times are forbidden, and all others are allowed.

Jason Bell (13l0y-jason) wrote :

Just a quick plus 1 for this feature.

For what it's worth I would also like to see granularity for both the zones and times but the most important is certainly times as we have un-metered internet at night.

Otto Kekäläinen (otto) wrote :

I think the point with Deja Dup is to be simple and have such defaults, that users very seldom need to change them. There is already the possibility for advanced users to run "deja-dup --backup" in the command line and schedule that command with some graphical cron tools if they wish.

Before making the Deja Dup GUI more complex, we should first think trough if deja-dup-monitor can be improved to solve the use cases presented here. NetworkZones mentioned by Terry could be useful, but they have been dropped for Gnome 3.3: https://live.gnome.org/ThreePointThree/DroppedFeatures/NetworkZones

Deja-dup-monitor could apply these rules to postpone backing up:
- CPU/mem/hd/network shows high load (comment #6)
- ACPI shows laptop is running on battery (comment #5)

However, we don't want to postpone backing up forever, so there the user should be shown notifications when a too long time since last backup has passed (comment #7), e.g. "Warning: Deja Dup is set to backup weekly. However the last successful backup was 9 days ago. Please leave the computer idle, power plugged in and networked so that the backup can be run." After this notification the deja-dup-monitor should obviously check with a higher density (every minute?) if there are conditions to backup. Also the notification could at first come once a day for a week, then three times a day for a week, then hourly etc..

Also, for advance users there should be a log available where we can check what deja-dup-monitor has done. The natural place for a log file would be under ~/.cache/deja-dup/ since that is also where other apps like gwibber, zeitgeist, ubuntuone and shotwell keep this kind of logs. In the log deja-dup-monitor should save at least all times a backup succeeded or failed, what time it was and how long it took to complete.

After this is implemented, the log could be used to make an more "intelligent" algorithm to schedule backups. For example, if the successful backups are really fast on evenings between 18-22 (indicating that the user is at home close to his NAS appliance), then deja-dup-monitor could favour that time. This last paragraph of course needs more design, maybe I'll write down some more ideas later.

I don't understand the resistance to simply doing what many people are asking for. I provided a simple solution in comment 14. It certainly isn't the only way, but it would give us what we want and it isn't *at all* complicated. Or, I could also live with an approach that blacklisted certain times.

Otto's recommendations couldn't handle all the use cases, or they wouldn't handle them as well:

- First, he recommends running deja-dup --backup via cron. This is OK, I guess, but how are users who aren't watching this bug to know about the --backup switch. Usually, Gnome-ish apps don't have useful command line options, so it's not generally worthwhile to try to figure out how to run them that way. Some other drawbacks: If X doesn't happen to be running at the scheduled time, what happens?

- Examining the load and battery status would only be a partial solution. The thing is, it can't predict in advance which times would be bad to start the backup. So if my netbook with limited resources is idle while I'm teaching a class, deja-dup might decide that the conditions are right to run. But then, perhaps shortly thereafter I'll need the full resources of my machine and won't want to waste time pausing or stopping deja-dup. Handling this kind of situation is very simple if you can set a schedule, but very complex otherwise.

- Finally, Otto suggests choosing a backup time based on historical data. Again, this would work for some use cases, but not for others. In my case, my machine is connected to the same network most of the time. In addition, while I want my machine to be available during class, I don't use it in class every day. In many cases, I can't predict in advance when I'll need it. Furthermore, my class schedule changes every two months, which would make any historical data obsolete.

I'm not necessarily opposed to Otto's ideas. They could address some of the concerns. And indeed, it's best for deja-dup to have sensible defaults that most people won't need to change them. But as deja-dup is now part of Ubuntu's default install, it's important to support as many use cases as reasonably possible.

Nobody has critiqued my suggestion in comment 14. And I don't understand what the objections could be. The most commonly-raised objection is that of making the GUI more complicated. But there's plenty of room in the GUI for the options I suggested adding, and they're easy to understand, so there's really no significant added complexity there.

I'm urging the developers to be willing to consider adding more detailed scheduling. It's the only way to address all use cases presented.

Patrick Dickey (pdickeybeta) wrote :

Out of curiosity, how difficult would it be to place a setting like this:

Backup between the hours of ______________ and ______________ (24/hour format)

into the options, and then configure deja dup to only run during those hours? This would especially be useful on the daily backups, but is useful all around.

Have a great day:)
Patrick.

Me too +1.

I'd like to be able to choose what days of the week to backup and also what time to backup.

Colin Adams (colinpauladams) wrote :

I have two users on my system (myself and my wife). I want to be able to schedule my backups to occur at 02:00, and hers to occur at 04:00.

What crontab entries do I have to create for this to work. How is the current daily schedule kicked off (is it hard-coded into the program, or does it use cron)?

The normal way of working doesn't use any crontab entries. However, comment 18 mentions calling the - - backup option. Presumably, with a bit of fiddling you could make it work. I personally no longer use this software for a host of reasons, one of which is this bug.

Colin Adams (colinpauladams) wrote :

Thanks Scott,

I'm just trying it, as it comes with Fedora 17 as a standard tool.
What do you use instead?

@Colin: I'm currently using CrashPlan.

I was going to recommend CrashPlan also. I found it through another
project that I'm using (Amahi Home Server), and it's a better system
than Deja Dup (at least in it's current incarnation with this bug).

Have a great weekend.:)
Patrick.

On Fri, 2012-09-14 at 14:09 +0000, Scott Severance wrote:
> @Colin: I'm currently using CrashPlan.
>

Daniel Castro (castromd) wrote :

+1

I'd also like more flexibility here. Just like the kind of flexibility gnome-schedule provides.

Daniel Castro (castromd) wrote :

Does anyone here knows exactly how scheduling works today?

I found this: https://answers.launchpad.net/deja-dup/+question/123192
Is that explanation accurate?
Where can I find deja-dup's documentation?

+1
Seems fundamental to perform backup during user-defined down time.
Thanks for a great application!

Ankur Sinha (sanjay-ankur) wrote :

Hello,

I have a use case for this feature. I was back in India (GMT +5.5) a few months ago, and the backup used to run somewhere during the night when I wasn't using the system, which was perfect. Now, I've moved to Sydney, which is (GMT + 11). The backup now runs at 11AM, which is right at the start of work. It isn't such a big issue, but I'd like to be able to schedule it to run during the night when my system isn't doing anything, like it used to. Does the backup run at 0000GMT? Can this be modified to run at 0000 localtime instead as a temporary workaround?

+1 for the feature :)

Thanks,
Warm regards,
Ankur

Sam Shiell (samopn) wrote :

Hello

Can I be yet another person asking for a time-scheduling option. I have just a limited amount of download quota a month but it's free between 00:00 and 08:00 so that's the time I need to do my backing-up (I backup to Ubuntu-One). I can't afford to do this during my "paid for" quota times.

Also, as has already been mentioned, this ability seems pretty standard for a backup tool. Can't understand why it wasn't designed in at the beginning.

Cheers

Sam

This can't be scheduled by cron, because it needs password to be entered by user.

Sam Shiell (samopn) wrote :

Hey, I've just thought of something.. maybe we can attack this from the a different angle.

We know 2 things:-

1. Deja-Dup knows when it last did a successful backup.... it tells you when it was and it must have to know so that it knows when it has to kick off the next schedule.

2. It runs scheduled backups at more or less the same time of day as the previous successful back completed.

So, somewhere them MUST be something saved that has a date/time stamp in. Yes? If so then I can think of no reason why this can't be manipulated to "force" the next back to happen when we want it to.

What do you think?

Sam

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Related blueprints