'metadata' file not found when creating backup ("Could not restore ‘/home/user /.cache/deja-dup/metadata’: File not found in backup"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Déjà Dup |
Fix Released
|
Medium
|
Unassigned | ||
duplicity (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
Linux release: Ubuntu 13.04 64bit
Kernel: 3.8.0-29-generic
Python: 2.7.4
Deja Dup: 26.0
Duplicity: 0.6.21
Hi. I've tried to do my monthly or so backup recently, but Deja Dup crashed after trying to backup a very large file (VM disk with Windows 7, 50GB or so). I tried to do another one, this time excluding all my large VM's. However, now when trying to do a backup I'm getting the following error a few seconds after inputting my encryption password:
Could not restore ‘/home/
I've tried reinstalling both deja-dup and duplicity, purging duplicity, deleting deja-dup and duplicity from /home/tom/.cache, deleting the backup files on the external drive, deleting it's config as described here http://
Tom Slominski (tomslominski) wrote : | #1 |
description: | updated |
Tom Slominski (tomslominski) wrote : | #2 |
1 comments hidden Loading more comments | view all 107 comments |
Tom Slominski (tomslominski) wrote : | #4 |
Tom Slominski (tomslominski) wrote : | #5 |
Normal duplicity command line backups work fine, so this is probably a Deja Dup bug.
summary: |
- 'metadata' file not found when creating backup + 'metadata' file not found when creating backup ("Could not restore + ‘/home/user /.cache/deja-dup/metadata’: File not found in backup" |
Changed in deja-dup: | |
status: | New → Confirmed |
Alistair Grant (akgrant0710) wrote : | #6 |
I've seen this bug only once, after I paused the backup and re-started it. The following backup completed successfully.
Michael Terry (mterry) wrote : | #7 |
Do not run the command in comment #3! As Tom notes, that will delete a lot of configuration data for all of your programs, not just Deja Dup.
This error is happening during Deja Dup's test restore. In each backup, it includes this tiny file and after each backup, it tries to restore it. This is a way to verify that the backup is restorable on at least a basic level.
Tom, from your log, it looks like your backup got interrupted/
Changed in deja-dup: | |
importance: | Undecided → Medium |
status: | Confirmed → Incomplete |
Tom Slominski (tomslominski) wrote : | #8 |
I highly doubt that it got interrupted. The only way it could've been interrupted is hard drive issues, which is unlikely as I don't remember the drives becoming inaccessible afterwards. However, my hard drive enclosure is held together with a rubber band, which says it all really.
I'll be doing more backups as soon as possible so I'll get back to you then about whether this is still an issue.
Simon Langley (simon-ouryard) wrote : | #9 |
It happens everytime I do a backup. Maybe interrupting deja-dup is a problem but from what you've said why would it persist?
Michael Terry (mterry) wrote : | #10 |
Simon, I can't speak to your issue. I was looking at the logs provided by Tom, who opened this bug.
This error message might happen for several reasons, and I would need to see the log to determine why.
Tom Slominski (tomslominski) wrote : | #11 |
Nope, still getting this. It happened on Ubuntu 13.10, deja-dup 27.3.1-0ubuntu1, duplicity 0.6.21-0ubuntu4.1. I started doing an initial, encrypted backup and it came up with a restore test: http://
Tom Slominski (tomslominski) wrote : | #12 |
Definitely still happening, while a duplicity backup works fine. I can try the nightlies next time I do a backup. Would that be helpful? What kind of logs would you need if I was to do so?
Helmut Neubauer (helmut-8) wrote : | #13 |
I've the same problem to. I stopped a backup manually per GUI. Now, no backup works.
Nothing helps. I tried to delete .cache/deja-dup, I tried to initialize a new backup at a new location, but the problem still exists.
Paul Drain (pd) wrote : | #14 |
Had this on a fresh Ubuntu 14.04 Daily Image too (2014-02-12):
I had configured the backup settings as normal (to local, freshly formatted EXT4 USB stick), and closed the window -- half an hour later, the error popped up on the screen.
However, if I remove my deja-dup preferences from dconf and delete the .cache/deja-dup directory and try the process on a fresh stick _and_ press "Backup Now" (rather than letting it do it), the backup goes through & works fine.
Both a selected restore (from Nautilus) and a full restore (from Deja Dup, to an empty directory on the host drive) work from both sticks without errors though.
What's the preferred way to provide debug logs to find the problem?
WoodyEckelzone (bcr497) wrote : | #15 |
Also have this every time. 13.10
WoodyEckelzone (bcr497) wrote : | #16 |
BTW my home folder is on SSD and
~/.cache is symlinked to an harddrive
Can that cause the problem?
Brandon P. (brandonmpace) wrote : | #17 |
I replicated this on 14.04 by symlinking ~/.cache to another partition. (home on SSD)
All was fine before this.
Sébastien Lerique (wehlutyk) wrote : | #18 |
I also have this bug on Debian Jessie, but note that in the settings I am excluding ~/.cache from the files to back up. If Deja Dup is testing a restore with a file from ~/.cache, it's logical that it fails. Do any of the people above also have ~/.cache excluded from the backups? If not, I'll file a new bug since this is different.
$ uname -a
Linux iona 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux
$ dpkg -s deja-dup
Package: deja-dup
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 5597
Maintainer: Debian GNOME Maintainers <email address hidden>
Architecture: amd64
Version: 30.0-1
Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.2.4), libgdk-pixbuf2.0-0 (>= 2.22.0), libgirepository
Recommends: gvfs-backends, python-boto (>= 0.9d), python-cloudfiles, ssh-client | openssh-client
Conffiles:
/etc/xdg/
Description: [...]
Michael Terry (mterry) wrote : | #19 |
~/.cache is always excluded anyway. As I mentioned in comment #7, this is a deja-dup internal sanity check on your backup. It creates a file in ~/.cache and includes it in each backup as a canary-
Maarten Vergauwen (maarten-vergauwen) wrote : | #20 |
I tried it on a fedora 20 machine with the same result.
Similar to comment #16, my home dir is actually a symbolic link to another disk.
IMO chances are high this triggers the bug.
versions on fedora:
deja-dup-
3.14.4-
Joe (jgerm54654378955) wrote : | #21 |
Like others, this bug only occurred for me once I changed my cache directory to a symbolic link to another drive.
rubo77 (rubo77) wrote : | #22 |
Please someone with therights delete the comment #3! As Tom notes, that will delete a lot of configuration data for all of your programs, not just Deja Dup.
Jim Caughran (caughranjim) wrote : | #23 |
Note that like others, my .cache is a link to a larger disk. Ubuntu 14.4
I wondered if an empty file would suffice, and created a file in .cache/deja-dup/. I started deja-dup from the windowskey launcher. It asked if I wanted a password on the backups, then started to create "first backup". I checked the folder, and discovered that it had removed all previous backups. In .cache, it converted by empty file to a folder with a single file in it, README:
This folder can be safely deleted.
1405284829
It's working on the backup now. If it fails, I'll change this.
Jim Caughran (caughranjim) wrote : | #24 |
Nope. After the backup,
Could not restore ‘/home/
The folder it created disappeared.
Bib (bybeu) wrote : | #25 |
14.04 fresh install. Trying to backup ("weekly") my whole home to external (usb) dedicated NTFS drive I also meet this error stating I should "remove" my backup. Deleted all partitions and reformat the whole as ext4, retried, same error. Then I tried excluding the huge part (my pictures tree). This time it worked, so I went on, removing some folders out of exclusion list, and forcing "backup now" ... worked ok.... went on until time to go to bed when I shut the PC down (until this moment, deja-dup main tab showed "Next backup will happen tomorrow). This morning I want to go on, remove some more folders out of exclusion list.... and the error is here again :( (this time I'm not advised to remove the backup) ... I retried, keeping the exclusion list as is, and this time it worked again. I can't remember what the schedule info was this morning when I first ran deja-dup, but at the moment it is "Next backup will happen in 7 days". I go on each time removing some sub-folders out of the exclusion list, and it still seems to work.
Maybe a schedule triggering issue?
Changed in deja-dup: | |
status: | Incomplete → Confirmed |
tags: | added: 14.04 |
1 comments hidden Loading more comments | view all 107 comments |
Bib (bybeu) wrote : | #27 |
I compared with a OK-running other laptop and this maybe strange diff in gsettings:
OK laptop
org.gnome.
KO laptop
org.gnome.
Bib (bybeu) wrote : | #28 |
- DejaDup ls and gsettins.txt Edit (3.0 KiB, text/plain)
repost clean
Comment 26 for bug 1217959
Bib (bybeu) wrote 1 hour ago: #26
Yesterday in the evening I changed the backup target from the usb drive to a network folder though ssh. At this time the proposed/previous target was "Sauvegarde". I didn't choose the proposed remote $HOME/.../deja-dup/ target, but instead a customized [remote]
During the backup the laptop went to sleep state several times until I disabled sleep feature and he went on backing-up until this morning ~4h AM, but no time since backup start deja-dup stated an error. Only in the end displayed the error stating "Backup failed" Unable to **RESTORE** /home/marie/
The $HOME is on a SSD and this is no external .cache symlink or any here in (single drive in the laptop). At the moment I still have the failure popup displayed but I can't find any log.
Attached are list on the target, showing backup ran until the end (~40GB data), a list of local deja-dup folder and settings:
Have a look at time/date/size to make sure ~start time and end time.
I can add that only once in the process I had a look at "Details" expanding the list, then I closed it, feeling this was maybe involved in previous failures I experienced.
Daniel Koć (kocio) wrote : | #29 |
For me the root of the problem was interrupted backup. Removing .cache/deja-dup dodd not help, but after:
dconf reset -f /org/gnome/
(and making references once again) the backup starts. So, probably the problem lies in some bad dconf entries after not succesful backup process.
gaolugang (gaolugang) wrote : | #30 |
#29 works for me. My problem was also that I interrupted the previous backup and this problem keeps happening after that.
gregor (gregor-6) wrote : | #31 |
hi,
i have her the same problem. i tried as destination local file and ssh.
environment: ubuntu 14.04 x86_64 (kernel 3.13.0-35)
deja-dup 30.0
a reset of the dconf settings + deleting .cache/deja-dup did not help
Simon Zwölfer (simon-zwoelfer) wrote : | #32 |
Hi, just the same for another two environments. Like in Post #31 reset of the dconf settings + deleting .cahce/deja-dup did not help. Another fact is, that a test-restore of a file that should be included in the backup via nautilus does not work, too.
Dario Nuevo (wee-xbe) wrote : | #33 |
I'm in the same boat. LTS 14.04, reset dconf and deleting .cache/deja-dup didn't help..
Also, I've observed an odd behavior: In my case, it doesn't actually backup anything. It starts a fresh backup (when I've reset everything), and after some seconds skips to "verifying" directly, without having done a backup. Paths are OK; my user home is quite big. I don't know if I'm the only one having this behavior?
If somehow deja-dup isn't able to backup anything, it also makes sense that it doesn't find the .cache-test-file in the backup of course ;-)
Important: In my case, my whole /home/[user] is a bind mount (`mount -o bind`) to another disk - could that be an issue?
** Is there any way to get the duplicity commands what deja-dup is using, or any other method to know what it's actually doing? Any way to see under the GUI? Any logs, any --verbose switch? (didn't see any..?)
Dario Nuevo (wee-xbe) wrote : | #34 |
It seems deja-dup (or duplicity) has a problem with backup folders that are either symlinks and/or bind mounts.
Please see my comment #33 above regarding my situation. Here, /home/[user] is symlinked to /mnt/data/[user] and no backup is performed - it just skips it failing with the error this issue here is about. Most other people here say, they symlinked/
As a test, i added /mnt/data/[user] (the source of the bind mount; thus the same files) to the backup folders. It is now backing up.. it takes some time as it's initial.. But i bet it will also fail with the same error, as ~/.cache is still on the bind mount (as /home/dn [the bind mount target] is still in the backup set)..
I think we should rename this issue to clarify.. I suggest duplicity/deja-dup are not correctly handling symlinks and/or bind mounts. Just a guess, but would make sense.. how to be sure?
Dario Nuevo (wee-xbe) wrote : | #35 |
Ah, one correction to my last post (no edit function?)
I wrote
> Here, /home/[user] is symlinked to /mnt/data/[user]
It should be
> Here, /home/[user] is a bind mount (`mount -o bind`) of /mnt/data/[user]
Nathaniel Homier (mechamechanism) wrote : | #36 |
What is the work around to make deja-dup work in the GUI.
Jim Caughran (caughranjim) wrote : Re: [Bug 1217959] Re: 'metadata' file not found when creating backup ("Could not restore ‘/home/user /.cache/deja-dup/metadata’: File not found in backup" | #37 |
I gave up on it. I wanted to put .cache into RAM storage, and creating a
backup there was just too much.
I use simplebackup, which is quite good.
===========
Jim Caughran
<email address hidden>
On 24 October 2014 11:34, Nathaniel Homier <email address hidden>
wrote:
> What is the work around to make deja-dup work in the GUI.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> 'metadata' file not found when creating backup ("Could not restore
> ‘/home/user /.cache/
>
> To manage notifications about this bug go to:
> https:/
>
Dabo Ross (daboross) wrote : | #38 |
This is happening to me after after upgrading to 14.04, this worked fine before in 12.04. I have ~/.cache/deja-dup symlinked to /media/
If I remove the symlink the backup works, but it uses practically all of my home partition space.
arne (ubuntu-stukjewebgebeuren) wrote : | #39 |
Happing to me too. I also have .cache/deja-dup symlinked to elsewhere, in my case to a folder on a extra hard drive. When I change the symlink back to a regular folder, backup runs fine.
Brandon P. (brandonmpace) wrote : | #40 |
After looking at the code, I would prefer an option to specify the path to the deja-dup metadata file. (at least a config file edit, if not a GUI addition)
It seems to me it is coded to stick to the user's cache directory. (and duplicity may not be handling the symlink correctly)
no longer affects: | deja-dup (Arch Linux) |
27 comments hidden Loading more comments | view all 107 comments |
Marius Nuennerich (mwrius) wrote : | #68 |
Still happening on 16.04.
I *DON'T* have .cache symlinked anywhere. I triggered this by manually starting a backup through the preferences window. I have Deja-Dup configured to run daily and a few hours ago the automatic run for the day already ran.
Leon Arundell (leon-arundell) wrote : | #69 |
Please upgrade the status of this bug to "High."
It has occurred several times on my Ubuntu 14.04 system in the past two months, and means that I cannot reliably use Duplicity to do incremental backups. The main alternatives seem to only offer time- and space- consuming complete backups.
Kenneth Loafman (kenneth-loafman) wrote : | #70 |
Go here <https:/
the repository to your list. apt-get update / upgrade will bring in the
latest version which is a lot newer than the one you have.
0.6.21 is at least 3 years old and has been superseded.
On Wed, Jun 1, 2016 at 3:46 AM, Leon Arundell <email address hidden>
wrote:
> Please upgrade the status of this bug to "High."
>
> It has occurred several times on my Ubuntu 14.04 system in the past two
> months, and means that I cannot reliably use Duplicity to do incremental
> backups. The main alternatives seem to only offer time- and space-
> consuming complete backups.
>
> --
> You received this bug notification because you are subscribed to
> duplicity in Ubuntu.
> https:/
>
> Title:
> 'metadata' file not found when creating backup ("Could not restore
> ‘/home/user /.cache/
>
> Status in Déjà Dup:
> Confirmed
> Status in duplicity package in Ubuntu:
> New
>
> Bug description:
> Linux release: Ubuntu 13.04 64bit
> Kernel: 3.8.0-29-generic
> Python: 2.7.4
> Deja Dup: 26.0
> Duplicity: 0.6.21
>
> Hi. I've tried to do my monthly or so backup recently, but Deja Dup
> crashed after trying to backup a very large file (VM disk with Windows
> 7, 50GB or so). I tried to do another one, this time excluding all my
> large VM's. However, now when trying to do a backup I'm getting the
> following error a few seconds after inputting my encryption password:
>
> Could not restore ‘/home/
> in backup
>
> I've tried reinstalling both deja-dup and duplicity, purging
> duplicity, deleting deja-dup and duplicity from /home/tom/.cache,
> deleting the backup files on the external drive, deleting it's config
> as described here http://
> all-the-
> supporting this) that the drive itself isn't faulty as I managed to
> backup my old laptop to the drive using duplicity and it worked fine
> (Fedora 19, deja dup 26.0 I think). I will upload the appropriate logs
> momentarily.
>
> To manage notifications about this bug go to:
> https:/
>
Leon Arundell (leon-arundell) wrote : | #71 |
I tried Rob Frohne's suggestion of adding ~/.cache.deja-dup to my "Folders to ignore" list, and it has worked at least temporarily.
I also tried Kenneth Loafman's suggestion of updating duplicity, but the installation instructions didn't seem to work.
cement_head (andorjkiss) wrote : | #72 |
@leon-arundell What do you mean by "I also tried Kenneth Loafman's suggestion of updating duplicity, but the installation instructions didn't seem to work."?
Do you mean to say that you couldn't add PPA, update the cache and upgrade Duplicity? Or do you mean that after upgrading Duplicity, there was no change?
Launchpad Janitor (janitor) wrote : | #73 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in duplicity (Ubuntu): | |
status: | New → Confirmed |
Changed in duplicity (Ubuntu): | |
status: | Confirmed → Incomplete |
novoid (v-launchpad-karl-voit-at) wrote : | #74 |
I am affected by this bug with a current Xubuntu 16.04 LTS.
My ~/.cache is a symlink to a different SSD/partition if this matters. Since ~/.cache/deja-dup filled up my root parition (before symlinking it), I had to manually delete ~/.cache/deja-dup and the files in the backup destination. Maybe this had some effect as well.
Mike Gerber (mikegerber) wrote : | #75 |
I am seeing this on Ubuntu 16.10. ~/.cache/deja-dup/ is on the /home filesystem.
$ dpkg -l duplicity deja-dup
Desired=
| Status=
|/ Err?=(none)
||/ Name Version Architecture Description
+++-===
ii deja-dup 34.2-0ubuntu amd64 Back up your files
ii duplicity 0.7.06-2ubun amd64 encrypted bandwidth-efficient bac
Mike Gerber (mikegerber) wrote : | #76 |
$ ls ~/.cache/deja-dup/
4d801e19c0c7ed7
Felipe Castillo (fcastillo.ec) wrote : | #77 |
I have this exact same problem. I tried creating an empty metadata file so it can write over it, but that didn't work.
I decided to symlink only the folder inside '.cache/deja-dup', the folder named 6724d3f170e0390
"Specified archive directory '/home/
Well, I guess it's technically not a directory, it's a symlink to one.
Has anybody come up with a workaround for this? Anything?
Dabo Ross (daboross) wrote : | #78 |
I've worked around this by using a bind mount instead of a symlink. Something like 'sudo mount --rbind /run/media/
If you also do a `chmod 500 ~/.cache/deja-dup` when it's unmounted, deja-dup will be unable to write any files to the unmounted directory and it will fail early - so you can then mount it and re-start the backup.
Xwarman (xwarman) wrote : | #79 |
That bug is now over 3 years old and still existent. In the default backup software of ubuntu... I... am just wondering.
Well. Can I still use it and are the backups usable anyway? Can I trust them with that error?
Thanks.
cement_head (andorjkiss) wrote : | #80 |
See Post#77 for the workaround, and yes, this will make it all work
@Xwarman: Please be aware that you disabled one of the major checks to ensure a successful backup.
@all: I am wondering if this happens before or after the backup taking place?
A more recent output of the file /tmp/deja-dup.log after running the appropriate line below and replicating the problem might be helpful as well. Especially because there seems to be another problem in the backup of the original reporter. You may want to scrub the log of any incriminating file names or details:
DEJA_
Setting this to Incomplete, because I am unable to verify without the information requested above.
Please reset to "Confirmed" after providing this information.
Changed in deja-dup: | |
status: | Confirmed → Incomplete |
Dabo Ross (daboross) wrote : | #83 |
When this last occurred for me, it happened after the backup was complete, or at least after the backup had been running for a while. I'm unsure if it was during, before or after the 'verification' phase.
Just now, when running the command you posted, the error did not occur. I haven't had this error anyways for quite some time since I've been using the workaround of having an rbind mount, but just now I re-did the symlink which caused the error before, and the error did not occur. I'm now using deja-dup 34.2 in Gentoo, and when it originally occurred I was using an earlier version of deja-dup in Ubuntu. I'm not sure if it's completely fixed for me, if my different setup can no longer reproduce the error, or if it just worked this one time, so if anyone else who had experienced in the past could test with deja-dup 34.2, that would probably be best.
Ricardo Graça (devius) wrote : | #84 |
@Vej I just saw this error this morning, but on my second attempt using the command you provided to get a log file there was no error. However, upon inspection of the log file I can see that it didn't process all "volumes". It was supposed to process 258 volumes, but the log file ends on volume 11. I have no idea what these "volumes" are, and they may be called something else in the English version. I'm using the Portuguese version.
Do you still want me to provide the log file?
@Ricardo If your log does still contain an line "DUPLICITY: ERROR 19" it might be helpful here. Otherwise I would think, that you are facing another bug.
Launchpad Janitor (janitor) wrote : | #86 |
[Expired for Déjà Dup because there has been no activity for 60 days.]
Changed in deja-dup: | |
status: | Incomplete → Expired |
Launchpad Janitor (janitor) wrote : | #87 |
[Expired for duplicity (Ubuntu) because there has been no activity for 60 days.]
Changed in duplicity (Ubuntu): | |
status: | Incomplete → Expired |
Dabo Ross (daboross) wrote : | #88 |
I thought this had been fixed, but I ran into something else very similar today:
When I had a symlink set for ~/.cache/deja-dup, deja-dup actually _deleted_ this symlink, and still filled up my home folder. I ran out of space and the backup failed.
Perhaps this is why it was succeeding for me, just by coincidence I had enough space at the time?
Or would it be better to make a new issue for this seeming deletion of symbolic links?
deja-dup 34.3
@Dabo Ross: Your problem seems to be different from this one, so a new bug report is a good idea.
Btw: Please refrain from exaggerating "a symlink set for ~/.cache/deja-dup gets deleted" to "deletion of symbolic links", because the handling of ~/.cache/deja-dup is a bit special (unless you see deletion of other symlinks as well).
Thanks
Vej
Dabo Ross (daboross) wrote : | #90 |
Alright, thank you. My apologies for the accidentally inflating the issue, I was not thinking through my comment much when I posted.
Michael Terry (mterry) wrote : | #91 |
Reopening. I can easily believe we don't handle a symlinked cache file well.
Changed in deja-dup: | |
status: | Expired → New |
Jared Stemen (jstemen) wrote : | #92 |
I just hit this bug. I recently put in a symlink for my ~/.cache directory. My deja dup version is as follows:
~/.cache$ apt list --installed | grep deja
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
deja-dup/
deja-dup-
deja-dup-
fonts-dejavu/
fonts-dejavu-
fonts-dejavu-
Hello Jared.
Thanks for letting us know about this.
Can you please add the file /tmp/deja-dup.log after running the line below and replicating the problem ? This is an old bug so a new log might be helpful for us to figure out what went wrong here:
DEJA_
Best Regards
Vej
Changed in duplicity (Ubuntu): | |
status: | Expired → Incomplete |
Changed in deja-dup: | |
status: | New → Incomplete |
Tuomo Sipola (tuomosipola) wrote : | #94 |
Still affects me. I have symlinked Deja Dup cache deja-dup -> /media/
Marcin Owsiany (marcin-owsiany-pl) wrote : | #95 |
- deja-dup.log Edit (99.1 KiB, text/plain)
vej, it affects me as well, using 34.3-1
Attaching the log.
In there one can see:
DUPLICITY: ERROR 19
DUPLICITY: . home/porridge/
And once I think about it, it makes sense, since /home is a symlink to /srv/home, and the metadata directory is there under the canonical path:
porridge@
GnuPG passphrase for decryption:
Thu Mar 1 17:16:19 2018 srv/home/
Thu Mar 1 17:16:19 2018 srv/home/
Thu Mar 1 17:16:19 2018 srv/home/
porridge@
How can I work around this?
Changed in deja-dup: | |
status: | Incomplete → Confirmed |
Marcin Owsiany (marcin-owsiany-pl) wrote : | #96 |
I'm wondering whether something like wrapping the Path.build_filename call located in libdeja/
Unfortunately I don't know vala well enough to test this idea.
Kirk Erickson (ekirk0) wrote : | #97 |
Deja calls the duplicity command. Monitors the progress and checks that it
finishes. Try getting the underlying command and manually calling
duplicity. When I last looked at this bug duplicity was performing the
backup job to completion. Backups we're ok. Just this error coming from
deja. After looking at the vala code it looked like a vala async call was
failing.
*Check your backups. Do they work?
*Try the deja debug mode to get logs.
export DEJA_DUP_DEBUG=1
deja-dup --backup > dump
Maybe this helps
On Mar 1, 2018 1:19 PM, "Marcin Owsiany" <email address hidden> wrote:
I'm wondering whether something like wrapping the Path.build_filename
call located in libdeja/
realpath() would be enough to fix this issue.
Unfortunately I don't know vala well enough to test this idea.
--
You received this bug notification because you are subscribed to the bug
report.
https:/
Title:
'metadata' file not found when creating backup ("Could not restore
‘/home/user /.cache/
Status in Déjà Dup:
Confirmed
Status in duplicity package in Ubuntu:
Incomplete
Bug description:
Linux release: Ubuntu 13.04 64bit
Kernel: 3.8.0-29-generic
Python: 2.7.4
Deja Dup: 26.0
Duplicity: 0.6.21
Hi. I've tried to do my monthly or so backup recently, but Deja Dup
crashed after trying to backup a very large file (VM disk with Windows
7, 50GB or so). I tried to do another one, this time excluding all my
large VM's. However, now when trying to do a backup I'm getting the
following error a few seconds after inputting my encryption password:
Could not restore ‘/home/
in backup
I've tried reinstalling both deja-dup and duplicity, purging
duplicity, deleting deja-dup and duplicity from /home/tom/.cache,
deleting the backup files on the external drive, deleting it's config
as described here http://
all-the-
supporting this) that the drive itself isn't faulty as I managed to
backup my old laptop to the drive using duplicity and it worked fine
(Fedora 19, deja dup 26.0 I think). I will upload the appropriate logs
momentarily.
To manage notifications about this bug go to:
https:/
Marcin Owsiany (marcin-owsiany-pl) wrote : | #98 |
Kirk, I think you missed my update #95, which explains the root cause.
@Marcin For a workaround you can try mounting with --bind instead of symlinking.
If you do, please let us now if this worked for you.
Best
Vej
Marcin Owsiany (marcin-owsiany-pl) wrote : | #100 |
I tend to avoid bind-mounts because they confuse disk usage calculation
programs.
What I ended up doing was use "usermod" to set the home to canonical path.
deja-dup works now, and surprisingly I haven't notice any other app break
(so far).
2018-03-04 21:18 GMT+01:00 Vej <email address hidden>:
> @Marcin For a workaround you can try mounting with --bind instead of
> symlinking.
>
> If you do, please let us now if this worked for you.
>
> Best
>
> Vej
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> 'metadata' file not found when creating backup ("Could not restore
> ‘/home/user /.cache/
>
> Status in Déjà Dup:
> Confirmed
> Status in duplicity package in Ubuntu:
> Incomplete
>
> Bug description:
> Linux release: Ubuntu 13.04 64bit
> Kernel: 3.8.0-29-generic
> Python: 2.7.4
> Deja Dup: 26.0
> Duplicity: 0.6.21
>
> Hi. I've tried to do my monthly or so backup recently, but Deja Dup
> crashed after trying to backup a very large file (VM disk with Windows
> 7, 50GB or so). I tried to do another one, this time excluding all my
> large VM's. However, now when trying to do a backup I'm getting the
> following error a few seconds after inputting my encryption password:
>
> Could not restore ‘/home/
> in backup
>
> I've tried reinstalling both deja-dup and duplicity, purging
> duplicity, deleting deja-dup and duplicity from /home/tom/.cache,
> deleting the backup files on the external drive, deleting it's config
> as described here http://
> all-the-
> supporting this) that the drive itself isn't faulty as I managed to
> backup my old laptop to the drive using duplicity and it worked fine
> (Fedora 19, deja dup 26.0 I think). I will upload the appropriate logs
> momentarily.
>
> To manage notifications about this bug go to:
> https:/
>
Michael Terry (mterry) wrote : | #101 |
Sorry for ignoring this for so long! I've got a patch in master for this and a few related symlink-restore issues. Fix should be in the 38.3 release.
https:/
Changed in deja-dup: | |
status: | Confirmed → Fix Committed |
Changed in deja-dup: | |
status: | Fix Committed → Fix Released |
Sergey Shik (pjss) wrote : | #102 |
Updated to latest version but still got that error
ii deja-dup 39~bzr1796~u amd64 Back up your files
ii duplicity 0.7.17-0ubun amd64 encrypted bandwidth-efficient bac
my .cache/deja-dup symlinked to another folder
P.S. is it possible to include cache location option in preference?
Bas Roufs (basroufs) wrote : | #103 |
Working at a fresh install of Kubuntu 18.04.1 LTS in February 2019 - at a Lenovo X220, with a i5 processor and a 1 TB Samsung 860 EVO SSD, together with a 4 TB external HD, "WD My Passport". However, I still stumble upon the same bug. However, I seemingly manage to work around it by acting as follows:
TERMINAL >> sudo apt-get purge deja-dup duplicity > sudo apt-get autoremove > sudo reboot now > after the reboot: TERMINAL >> apt-get install deja-dup duplicity > sudo deja-dup.
On one hand, deja-dup has been making a first back-up ever since I hit the "sudo-deja" commando - now, a few hours ago.
On the other hand, I got this terminal feedback in the first minutes after hitting the "sudo deja-dup" commanend.
bas@Viaconsensu
** (org.gnome.
gpg: WARNING: unsafe ownership on homedir '/home/bas/.gnupg'
** (org.gnome.
After "Timeout was reached", deja-dup seemingly started the backup process that is still ongoing.
I keep you posted here on my experiences.
Yours,
Bas G. ROufs.
Bas Roufs (basroufs) wrote : | #104 |
Bas Roufs (basroufs) wrote : | #105 |
Savvas Shiakas (shiakas) wrote : | #106 |
Hey guys, I don't think this is a solution but it didn't produce the error so here it goes:
1. created a folder and named it "backups" in the home directory
2. changed the Storage location of the backup to the "backups" directory
3. created the backup and no error :)
Previously my storage location was the home directory.
(I am new to Ubuntu/Linux)
Kenneth Loafman (kenneth-loafman) wrote : | #107 |
Please upgrade to the current version of duplicity. This will assure that any bugs fixed since your release are available and may fix your issue.
NOTE: This applies especially to duplicity versions between 0.7.03 and 0.7.14 inclusive. There was a fix in 0.7.15 that reduced memory usage drastically, and will help with memory errors and inability to start new threads.
There are three options:
* Release tarball Install - https:/
* Daily duplicity builds - https:/
* Stable duplicity builds - https:/
NOTE: UNinstall duplicity first if it was installed via the distribution repository. For Ubuntu, that would be "sudo apt-get purge duplicity".
Doesn't that delete basically all the config for the up to date programme that use dconf?