Days since last backup

57 views
Skip to first unread message

tetra...@danwin1210.me

unread,
Nov 20, 2019, 10:12:40 PM11/20/19
to qubes...@googlegroups.com
The built-in Qubes backup functionality is great but it's very easy to
forget to run a backup and end up going days (or weeks, or months...)
without it.

MacOS has a handy feature where it will remind you if it has been more
than 10 days since your last backup.

This would be great to have in Qubes. And it shouldn't be that hard to
run a daily cron job that pops up a notification if there hasn't been a
backup for a while.

However, I am stuck on how to determine how many days it has actually
been since the last backup.

Potential options:
1) Assume all backups are done by a shell script, and that shell script
somehow saves the date to disk. How do we do this in an easy-to-parse
way?

2) Assume backups may happen by command line or GUI (assume we don't
know). Where can we find the date of the last backup on disk, and parse
it into an integer value that can be checked by a notification script?

Steve Coleman

unread,
Nov 21, 2019, 10:07:54 AM11/21/19
to qubes...@googlegroups.com
On 2019-11-20 22:12, tetrahedra via qubes-users wrote:
> The built-in Qubes backup functionality is great but it's very easy to
> forget to run a backup and end up going days (or weeks, or months...)
> without it.
>

> However, I am stuck on how to determine how many days it has actually
> been since the last backup.

What you are looking for is this command:

qvm-prefs --get $vm backup_timestamp

I have a script that when it runs, it queries all VM's that have not
been backed up since the last time they were run, and if they are not
currently running, it kicks off backup to sys-usb to back it up, each to
its own file. If I were to put this script in cron all I would have to
do is shut down a VM and it would automatically be backed up, though
that would likley cause problems if I restarted one that was gettign
backed up, so I don't generally leave it running in the background. So,
at the end of my work day I just shutdown what VM's I can and kick off
my script and my work for that day is always archived on a local LUKS
volume.

This works pretty well for me on a the local drive, but then I still
need to deal with issues with getting the "corporate backup software" to
spool those huge files off to the server farm at night in order to
fulfill my required retention policy.

tetra...@danwin1210.me

unread,
Nov 21, 2019, 8:44:20 PM11/21/19
to Steve Coleman, qubes...@googlegroups.com
On Thu, Nov 21, 2019 at 10:04:59AM -0500, Steve Coleman wrote:
>> However, I am stuck on how to determine how many days it has actually
>> been since the last backup.
>
>What you are looking for is this command:
>
>qvm-prefs --get $vm backup_timestamp

Perfect, thank you!

Bernhard

unread,
Nov 22, 2019, 4:41:21 AM11/22/19
to qubes...@googlegroups.com
However, I am stuck on how to determine how many days it has actually
>>> been since the last backup.
>>
>> What you are looking for is this command:
>>
>> qvm-prefs --get $vm backup_timestamp

Nice. In case of a "manual backup", can you also set the variable that
way? Like

qvm-prefs --set $vm backup_timestamp  2019.11.22-00:00:00

(or some other time format) ?

Steve Coleman

unread,
Nov 22, 2019, 9:21:10 AM11/22/19
to qubes-users
I believe it requires the Unix timestamp as a long int, but represented
as a string, so you would need to first convert your string to the Unix
long int representation.

The example command below is untested, but this should work to set the
backup_timestamp to the time value of some archive file taken from some
other non-qubes backup solution.

$ backup_timestamp=`date --reference=/path/to/my_backup.tgz +%s`
$ qvm-prefs --set $vm backup_timestamp $backup_timestamp

Or like you asked, you can just use the date command to convert any
standard time format string to the required unix timestamp value. If you
are using the qvm-backuprestore command like I am, then this is always
done for you for free, and you need not worry about managing the backup
timestamps yourself.

As a part of my backup script I also need to deal with freeing up enough
removable disk space for the pending backup session. My backup target
disk is managed as a set of folders, one per VM, and based on the
predicted backup size I roll though all the VM folders, sort that vm's
backup directory based on time, and remove only however many old backup
archive files from each directory that I need in order to free up that
required amount of space. This way I am guaranteed to have at least N
backups of each VM and only the older archives are removed as newer ones
are created.

Its a great feature that Qubes keeps tabs on the previous backup
timestamps in its VM database. That makes the complexity of custom
backups easy to manage using very simple bash/python scripting.

Steve

tetra...@danwin1210.me

unread,
Nov 25, 2019, 11:27:10 PM11/25/19
to qubes...@googlegroups.com
On Thu, Nov 21, 2019 at 04:12:25AM +0100, tetrahedra via qubes-users wrote:
>The built-in Qubes backup functionality is great but it's very easy to
>forget to run a backup and end up going days (or weeks, or months...)
>without it.
>
>MacOS has a handy feature where it will remind you if it has been more
>than 10 days since your last backup.
>
>This would be great to have in Qubes.

I've created a script and user-mode anacrontab to automatically remind
the user if it's been more than N days since the last backup.

Are the qubes-community-docs the best place to document this, or is
there a better place for things that involve scripts?

tetra...@danwin1210.me

unread,
Dec 9, 2019, 6:12:59 AM12/9/19
to qubes...@googlegroups.com
On Tue, Nov 26, 2019 at 05:26:54AM +0100, tetrahedra via qubes-users wrote:
>I've created a script and user-mode anacrontab to automatically remind
>the user if it's been more than N days since the last backup.
>
>Are the qubes-community-docs the best place to document this, or is
>there a better place for things that involve scripts?

Put in a PR for qubes-community-docs, in case anyone wants to review and
merge it.
Reply all
Reply to author
Forward
0 new messages