Backintime frozen: Working, save permission; Cancel, OK.

The 'free space' option in BIT is handled after the backup is done. It will remove old snapshots until there is enough space left. So if your actual backup will not fit on your drive, you have to free space manually before you make a new snapshot. You can mark the last snapshot and use the 'remove snapshot' button.

Did you exclude the other drive you where talking about from your BIT backup? Maybe this is the root of your problem. Your other drive fills up the backup and so you ran out of space...

Regards,
Germar

Thanks for the response and help, Germar. I'm not sure I understand all you've said.

If the free space option you speak of is the setting in BiT's preferences, I had that set to auto-remove if I had less than 1 gig of space. Apparently, it didn't work; it removed nothing; it just hung up. That's why I resorted to removing backups manually. Today, after posting this request (and thinking of how to do it), I removed about five old snapshots manually. Gparted shows what appears to be plenty of space for now, 11 gigs.

I assume that by mark the last snapshot, you mean highlight it. I don't see any actual marking feature. My BiT has no menu bar.

No, I didn't have BiT set to exclude any other drive. Rather, I told it to back up only the home folder on the drive containing it. I did make the mistake of having it back up root in two or three recent, earlier backups. Then I realized that that was a mistake and changed it to back up only the home folder, and that was what it was doing when it ran out of space and hung. I had not removed those root-level backups before running that last backup.

Even with the extra space newly created, I can't do another backup; BiT is hung up. I still have its icon in the system-tray part of the panel and can't remove it, and clicking it yields the little window saying "Back in Time/Save permission .../Ok Cancel." The last snapshot is not listed in BiT, but on the backup drive it's a folder listed as "New snapshot" that's not in the folder that contains the other snapshots. (Even those are not stored the way they used to be. They're nested in an additional folder labeled "1".) The new snapshot appears to be complete (I can't possibly check it all). So I can't remove that last snapshot with BiT. Is it necessary to do that to free up BiT, before being able to run another snapshot? I could do that manually.

Regards, and thanks again for the help.
Ray

I just noticed that that last backup is listed in BiT. It's called Now. I just tried to remove that; it didn't work. Apparently, BiT is frozen somehow. The "Take snapshot" and "Remove snapshot" icons are greyed out.

I could use the System Monitor/Processes to end the task, but I wonder if that would harm BiT, leaving it in a compromised condition.

Hi Raymond,

'Now' is not a snapshot. That is your current system like you can also see it with Nautilus (the filemanager). You can't remove that ;)

If BIT is frozen you can always kill the processes. BIT will remove the failed leftovers from the last session next time (as long as you don't activate 'Continue on errors') and start new.

The 'free space' option I was talking about is the 'If free space is less than' option in 'Auto-remove'. This is only handled AFTER a new snapshot was successfully created.

'New snapshot' is the folder on which BIT is currently working on. If the snapshot was successful (no errors) it will rename that to the current snapshot-id (date+time) like the other snapshots. They should all be in a folder structure like 'backintime/HOST/USER/PROFILE_ID/'

If you still ran out of space I would guess that your other drive you where talking about (the one that you have problems with) is still mounted and is included somehow in BIT backup.
Please run 'df -h' in terminal and look for filesystems that are mounted inside your /home/USER
You can either unmount them ('umount /home/USER/path/to/mountpoint') or you can add that path to the exclude list in BIT settings.

Regards,
Germar

Thanks, again, Germar.

And thanks for the enlightenment on what 'Now' is. Needed to know that.
If I'd remembered what BiT looked like before, when I was using it
regularly, I'd have known that, but I didn't remember seeing it.

> If BIT is frozen you can always kill the processes.
I did that, but it didn't remove the 'Save Permission' icon from the
Panel's System-tray area. And right-clicking it doesn't yield a quit,
delete, or move-to-trash option; it yields nothing. Left clicking it
simply displays the 'Save permission/Cancel, OK' window. And, since I have
two FSs mounted that Gparted says have lost their mount points, I won't
reboot the computer until I can regain those mount points. Also, when I
call up BiT, it still says at its bottom 'Working: Save permission ...'
and won't run a backup; 'Take snapshot' and 'Remove snapshot' are
inactivated.

> BIT will remove the failed leftovers from the last session
> next time (as long as you don't activate 'Continue on errors')
> and start new.
I look forward to that.

> The 'free space' option I was talking about is the 'If
> free space is less than' option in 'Auto-remove'.
> This is only handled AFTER a new snapshot was
> successfully created.
Yes, you said that before; I understood it.

> 'New snapshot' is the folder on which BIT is currently working on.
That's exactly what I thought and assumed.

> If the snapshot was successful (no errors) it will rename
> that to the current snapshot-id (date+time) like the other
> snapshots.
Since it didn't rename it, I guess that it hadn't finished. So ...

> They should all be in a folder structure like 'backintime/
> HOST/USER/PROFILE_ID/'
That's the structure that I've had in the past. But the new structure is
/media/GL_backup_1/backintime/lynn-desktop [this is new; before it was
/home] /lynn/ 1[This, too, is new.]/Date-named backups.

On Fri, May 17, 2013 at 1:16 PM, Germar <
<email address hidden>> wrote:

> Your question #228996 on Back In Time changed:
> https://answers.launchpad.net/backintime/+question/228996
>
> Status: Open => Answered
>
> Germar proposed the following answer:
> Hi Raymond,
>
> 'Now' is not a snapshot. That is your current system like you can also
> see it with Nautilus (the filemanager). You can't remove that ;)
>
> If BIT is frozen you can always kill the processes. BIT will remove the
> failed leftovers from the last session next time (as long as you don't
> activate 'Continue on errors') and start new.
>
> The 'free space' option I was talking about is the 'If free space is
> less than' option in 'Auto-remove'. This is only handled AFTER a new
> snapshot was successfully created.
>
> 'New snapshot' is the folder on which BIT is currently working on. If
> the snapshot was successful (no errors) it will rename that to the
> current snapshot-id (date+time) like the other snapshots. They should
> all be in a folder structure like 'backintime/HOST/USER/PROFILE_ID/'
>
> If you still ran out of space I would guess that your other drive you
> where talking about (the one that you have problems with) is still mounted
> and is included somehow in BIT backup.
> Please run 'df -h' in terminal and look for filesystems that are mounted
> inside your /home/USER
> You can either unmount them ('umount /home/USER/path/to/mountpoint') or
> you can add that path to the exclude list in BIT settings.
>
> Regards,
> Germar
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/backintime/+question/228996/+confirm?answer_id=4
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/backintime/+question/228996
>
> You received this question notification because you asked the question.
>

Maybe you didn't kill all processes. In Terminal please run 'ps ax | grep -E "(backintime|rsync)" ' this will give you a list of all processes. Please run 'kill -9 PID' on all processes where PID is the first number in that list.

The folder structure changed somewhere in version <1.0
BIT should've informed you about that on first start after updating. The old folders have been transformed to the new struckture automatically. This might be the root of your confusion.

I'm sure you're right that I didn't kill all processes. I used the System Monitor and killed only the top process, which obviously was the BiT program. I didn't look through the rest of the processes for other related ones.

After a few tries at your suggested command, I finlly got it to run. This is what it yielded:
28201 ? Sl 9:28 python /usr/share/backintime/common/backintime.py --backup
with the two 'backintime's in red. So I guess I still don't know what to do. Why haven't you told me how to do this in the System Monitor?

I haven't used this OS, UE, for about a year and a half. During that time, I've used Mint 12 (w/o running any backups), which I'm now trying to get all information from so that I can replace it with Ubuntu 13.04. I just regained access to UE's home folder (had it re-established) and, using BiT, restored my old data, then began running BiT again. This was just about three weeks ago. I believe that BiT has increased its version no. since I used it last (1.5 yrs ago). I think I upgraded it manually, but I don't remember its telling me anything about a changed storage structure. It may have.

Have you tried 'kill -9 28201' ?

I don't know what that is, but it worked. Thanks! Whew, one more problem solved. Three more (that I know of) to go. Dare you take the time to explain what the command meant? I'll bet that 28201 is the process no. for BiT.

'ps ax' print a list of all processes where the first column is the PID (a unique number for every running process)
'grep' will filter a given input through a pattern. The input will come from 'ps ax' because we pipe ' | ' the standard output of 'ps ax' into the standard input of 'grep'
with this you can run 'ps ax | grep -E "(backintime|rsync)" ' which will print all processes that have 'backintime' or 'rsync' in their name. In your case the frozen backintime process had the PID 28201

'kill -9 28201' will terminate the process with the PID 28201 immediately ('-9' is more or less brutal to the process. It doesn't allow him to close normally. But sometimes this is the only way to kill a frozen process)

That's a pretty good explanation. Thanks.