[Feature] Detailed scheduling

Adding my name to the list for needing this feature.

Thanks for a great backup application.

-crjackson

would be useful. Add myself too.

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

Hello,

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

- CH

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

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

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.

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

Just another hearty +1. Yes please.

+1 here to please

+1 for changeable scheduler

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.

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.

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.

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.

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.

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.

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.

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.
>

+1

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

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!

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

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

Here a temporary workaround : http://askubuntu.com/questions/54644/how-can-i-set-up-hourly-deja-dup-backups/67104

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

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

Any progress on this?

Count on me for this, or at least solve the problem with the "Waiting for <device> to become connected..." when called from cron and using an external disk that it IS actually connected.

A workaround for the "Waiting for <device> to become connected..." problem:

http://askubuntu.com/a/813341/105889

The problem here is that when a backup launches while you are using the computer this will most likely slow it down so much as to interfere with what you are doing. So you will end up canceling the backup to get your stuff done. So, effectively, there is no backup-ing. So, effectively, the backup tool ends up not serving its purpose.

So at least some sort of scheduling is necessary either to prevent the backups from being fired at certain days and/or times (ie "not on Mon,Tue,Wed,Thu,Fri 9:00-17:00"), or to only allow them to occur at certain days and/or times (ie "Saturdays or Sundays 00:00-08:00"). No need for fancy or complex scheduling rules, just keep it simple and useful for most cases.

For me this feature is a must. Deal-breaker if the backup tool does not support this.

I would also be able to reschedule the task. I am now stuck with a backup job running on Thursday mornings before work. If I don't have time it can't finish and I couldn't find a way to reschedule it to the weekend. That's really a bit annoying and I don't think these options would be an overkill.

@Johannes:

To reschedule a weekly backup to, say, Sunday, just start a backup manually on Sunday. Done.

Future automatic weekly backups will now happen on Sunday around the same time, assuming your computer is on and you're logged in of course. If you've gone on a vacation and only switch your computer on when you're back on Monday morning, Déjà Dup will notice the backup is overdue and will do it. That reschedules weekly backups to Monday mornings, so again, start a manual backup the next Sunday.

There is simplicity and then there is simplicity bordering on restrictive... why on earth do you think users want to keep 6 months of backups? 1 week is normally more than enough.

Deja-dup doesn't even create a proper log or at least drop a fail/success message to journald... I asked this on the mailing list, no reply as yet - a backup solution must create a proper high level log confirming failure or success, this is like backup software 101...

I think a group of us should just fork deja-dup and fix it!

As a workaround I have tried using dconf Editor to change the timestamps that deja dup uses to schedule its backups. Maybe this will work for other people too.

In dconf Editor go to:

    org/gnome/deja-dup

Change the last-backup and last-run timestamps to match a time earlier today that a successful backup should have run. For example, if you want to run backups daily, at 2am, try something like this:

2019-03-11T02:00:00.052453Z

This is within 24 hours, so the backup shouldn't bother you today. But hopefully at 2am the next day it will start working.

Give it a shot and see if it works for you. Maybe if we can confirm this we can either make a change to the deja-dup UI, or provide a simple command line tool to run to set this.

I made a discussion ticket on GitLab to gather the various suggestions we’ve received around more advanced scheduling options. I’m going to close this in favor of tracking the suggestions there.

https://gitlab.gnome.org/World/deja-dup/-/issues/111

Hi Michael,

Sorry, creating accounts is blocked ATM at https://gitlab.gnome.org

However, I would like to add one more option, which hasn't been mentioned there.

Where (not when) start the schedule update. I.e. your SSID (BSSID) at home is/should be a "safe harbor", but your work place or coffee, is a bit of a security/privacy risk.

Just my 2 cents.

Regards