OK, thanks. Marking bug as invalid.
For future reference, I think it is a bad idea to have two different
schedules and/or users back up to the same backup location, and it
actually seems to be not supported. It would be nice if this was
signalled and reported back to the user in a more transparent
*** CANCEL ***
I believe that this bug report can be CANCELLED.
As a result of continued experimentation, there appears to be a workaround.
So far the workaround has NOT failed. But testing has been less than 24 hours.
**Workaround:
The ADMINSTRATIVE version is set to backup to an external USB de
The automated backup worked for a while then stopped. It appears that
the ADMINISTRATIVE version is the one that hangs, since I have to enter
a password to cancel it. Unforutantley it won't let me cancel the job
for some reason. I am looking a the the /etc/sbackup.conf file and the
.config/sbackup
I can confirm, today, that executing the ADMINISTRATIVE vesion manually
resulted in both versions runnng. The manual execution was succesful. I
have revised both the ADMINISTRATIVE and USER versions so that they do
not backup the same files.
I hypothesise that there may be a conflict when both ver
I have actually done that (changed the permissions), or to be more precise
- I believe that I have done that.
To follow-up on what you say, I have "root" privileges. So I am both
ADMINISTRATOR and USER at the same time.
1. Through my "root" privileges I can schedule the Administrative version
to
Just chiming in with a suggestion here, not sure if it will help.
Could it be that when you run the backup as user, it fails to be able to
read the contents of the backup file because they are owned by root,
because (one of) the previous backup(s) was (were) made by root? And
this read-error is no
I finally separated the logs for the Administrator verson from the User
version. This error log is from the User version. The Adminstration
version worked. I have been wondering if having the two version creates
a confilct
PS: I have moved the back-up destination to a an external USB device
at
For a couple of days it seemed to work.
Today it froze. When I tried to clsoe it, it said that it could not be done.
I could not find a way to kill sbackup. It did not show-up as an active process.
Below is the log. When you look at the last line, there is no indication of
failure or completion.
S
SBackup 'Default Profile' Logger
==
2012-12-19 18:00:07,440 - INFO in ConfigManager.__create_logger(757): Log
output for [Default Profile] is directed to file
'/var/log/sbackup.2012-12-19_18.00.07.438819.log'.
2012-12-19 18:00:07,440 - DEBUG in ConfigManager.validateConfigFileOpts(806
The good and bad news, I received this dump. 12/17/2012
I did delete an earlier back-up, so i don't know if that had an effect.
---
2012-12-17 21:31:11,229 - INFO: Log output for [Default Profile] is dir
Thanks for responding. I am using Ubuntu Version 12.10. The manual
execution of sbackup works.
On Thu, Dec 13, 2012 at 4:53 PM, Jean-Peer Lorenz <
1087...@bugs.launchpad.net> wrote:
> Thank you for using sbackup and reporting this issue.
>
> I guess the issue you are encountering is related to t
Thank you for using sbackup and reporting this issue.
I guess the issue you are encountering is related to this:
2012-12-09 20:00:12,956 - ERROR: No such interface
`org.gtk.vfs.MountTracker' on object at path /org/gtk/vfs/mounttracker
What version of Ubuntu are you using?
Do manuell backups work
Found this log entry. Is this helpful?
---
Backup 'Default Profile' Logger
==
2012-12-09 20:00:12,629 - INFO: Log output for [Default Profile] is directed to
file
'/home/steve/.local/share/sbackup/log
sbackup log file output 12/9/2012
unfortunately does not mean much to me.
Updating DISPLAY to: :0
Updating SSH_AUTH_SOCK to: /tmp/ssh-AkWsSMP5ySFH/agent.1770
Updating GNOME_KEYRING_CONTROL to: None
Updating GNOME_KEYRING_PID to: None
Upda
14 matches
Mail list logo
