New releases / development

Remote backup it's not an easy job from BIT way of doing things.
It is planned ... but nothing done yet.

Regards,
Dan

I've added a branch providing remote backup over ssh. Feel free to test it.
https://code.launchpad.net/~germar/backintime/ssh

Thanks, I'll give it a try.
When you said it is only for GNOME for now it if only for GUI or it use some GNOME specific libs to do the real job ?

Regards,
Dan

No, I didn't use special libs. I just have not done the implementation for KDE jet. But if you like it and want to merge it with the main trunk or even if other users ask for it I'll do the work for KDE.
Right now I can say it run's stable for two days in production. I expected a lot more complications with in the mix of sshfs and direct access over ssh and so I'm really happy about how good it works.

Best regards,
Germar

Hi Germar,

Your changes looks very nice (very few changes in the code).

If I understand it right: the GUI need to mount / umount (to be able to explore snapshots) and the must take snapshot process run commands directly on the ssh host (+ rsync use ssh directly).

If it is true then maybe you can create/generate a "mount point" (for example in "~/.local/backintime/mnt/<porfile_id>").
(of corse the GUI should display the "current path" like "ssh://<host>:<port>/<path>" instead of just "<path>" like local mode)
What do you think ?

About the settings. I see more like having a combo with: "local" (default) and "ssh" (and maybe more).
For "local" it display the path (the editbox with the browse button) and for "ssh" display: host, port (with it's default value 22), path, ...
What do you think ?

Regards,
Dan

Hey Dan,
Thanks for your compliment. Both GUI and take-snapshot need the sshfs mount. I'm using the snapshot path (Config.get_snapshots_path()) as mountpoint to make thinks easy and minimize the changes in the code.

But I could just set snapshots_path default to ~/.local/backintime/mnt/<profile_id> if run in 'SSH' mode and hide the settings in the interface. This way we also would make sure, the users wouldn't use the same mountpoint for different users which would cause trouble. I've already set up a warning message in settingsdialog if mountpoint is not in $HOME to prevent this.
What should we do if the user switch back to 'local' mode? Just keep ~/.local/backintime/mnt/<profile_id> as snapshots_path till the user change it?
I don't understand exactly what do you mean with displaying the "current path"?

I like your idea of cleaning up the settingsdialog. That would make things lot smoother and SSH don't need to 'hide' under Advanced anymore.

Regards,
Germar

Hi Germar,

You can contact me by mail directly.
Forget about the "current path" suggestion. It was silly (I was thinking "lound" ... but realized it was stupid after sending the message).

I think it is easier to "hide" mount point to make it easier and avoid some problems.

You can change "config.get_snapshots_path()" to return the real path for "local" mode and the generated mount point for "ssh" (or maybe another remote) mode.

The mount point can be in "~/.local/backintime/mnt" or even better somewhere in temp (ex: "$TEMP/user/backintime/mnt") because it is erased on reboot so it can avoid some problems.

I think the mount stucture can be something like this:
<pid>.lock
<id>/
    mnt/
    dest
    <pid>.lock

Where:
  * <pid>.lock - a simple lock to avoid 2 processes modifying mounts at the same time
  * <id> - can be an id generated be be unique, so that different profiles (non only GUI & snapshot process) can share the mount point if they share the same "destination" (each profile has a snapshots profile folder but different profiles can backup on the same host)
      * dest: is text file that contains the real destination (ex: "ssh://<user>@<host>:<port>)
      * mnt: the real mount point
      * <pid>.lock: for each process that use this share there must be a file like this

In order to manage crashes you can check if a process "is alive" by sending a kill "0".

So the mount process can be like this:
* lock the mount folder: if there is already a lock check if the process is still alive: if not remove the "dummy" lock. If it is alive retry in 1-2 seconds (it can give up if it still can't lock after 1 min)
* clean up: mount points "that are not really mounted" and pid locks that are no longer alive
* if the ssh is already already mounted add a pid lock and the right id
* if the ssh is not mounted: mount it, wr

Regards,
Dan

...

* if the ss is not mounted: mount it, create dest file and add a pid lock
* then unlock the mount folder

What do you think ?

Regards,
Dan

I cannot contribute to this development but I just want to let you know - grist to your mill - that there are others who will be very happy to have this facility. I have read the details at https://code.launchpad.net/~germar/backintime/ssh - most of it I do not understand - but coincidentally I want to be able to use BackInTime to backup to my WD WhiteLight. If you want me to do any testing, please let me know.

Yours, Martin

Hi Martin,
Feel free to test it if you like. I would call it beta for now. So there could be some problems.
I've wrote down everything that need to be done in 'man backintime'. And I tried to do it more readable than in branch details. It would be nice if you could tell me if something is not understandable or if you find a bug.

Look at http://mybookworld.wikidot.com/optware on how to install optware on your WD MBWE. But like it is already mentioned in 'man backintime': please don't try to do this if you don't know what you do. And make a backup of your MBWE before starting.

Hi Germar

Many thanks! I have two questions:

(1) I am unsure how to actually obtain your update (you indicate it is in 'bzr..' I have never used this. If I install bzr does this mean I can obtain the update that I then copy to the backintime folder (forgive my ignorance)?

(2) Will backintime work with the WD MBWE without installing optware?

With thanks, Martin

Hi Martin,

(1) First you've to install bzr and gettext. Next you can download the branch and create .deb files which finally need to be installed.
Type in terminal:

sudo apt-get install bzr gettext
cd ssh
fakeroot ./makedeb.sh
sudo dpkg -i backintime-common* backintime-gnome* # or if you use KDE backintime-kde4*

(2) Sorry, that will not work. The BusyBox that is used by WD in MBWE for serving basic commands like 'cp' (copy) doesn't support hardlinks. Which is a rudimentary function for BackInTime's way to create incremental backups.

Regards,
Germar

Hi again Germar

Many thanks! (1) is now complete (I had to install, additionally, fakeroot).

I am now going to look into (2)!

Yours, Martin

Hey Martin,

I just remembered there is an other problem with the MBWE (sorry if you already struggled with it). The default home for users is /shares which is owned and only writeable by root. Also openssh-server is a bit fussy on allowing public-key access.

So here is the deal:
- create a new user <USER> for backup in MBWE's webadmin with a private share
- ssh login as root
- edit /etc/passwd and change users home from '/share' to '/shares/<USER>'
- make the new home rwx only by <USER> by typing 'chmod 700 /shares/<USER>'
- create the public-key on your computer and copy it over to MBWE like in 'man backintime'
- ssh login with <USER>@<MBWE> (you will still have to enter your password)
- make '.ssh' rwx only to <USER> by typing 'chmod 700 .ssh'
- log out and log in again. This time you shouldn't been ask for a password anymore

Regards,
Germar

Hi Germar
Many thanks again! I have not tried yet - I am saving this new adventure for the weekend! I will let you know how I fare.
Yours, Martin