Skip to content

First step to support new ftpfs BACKUP_URL #859

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
jsmeix merged 4 commits into from
Jun 3, 2016
Merged

First step to support new ftpfs BACKUP_URL #859

jsmeix merged 4 commits into from
Jun 3, 2016

Conversation

@jsmeix
Copy link
Member

@jsmeix jsmeix commented Jun 2, 2016

See #845

I tested it on SLE12 x86_64 kvm/qemu virtual machine
with BIOS and this /etc/rear/local.conf:

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=ftpfs://rear:[email protected]/rear
NETFS_KEEP_OLD_BACKUP_COPY=yes
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"

The currently supported ftpfs BACKUP_URL syntax is

ftpfs://user:password@host/path

where password is optional.

The only missing piece for me is that
in the rear recovery system one must
manually load the fuse kernel module with

modprobe fuse

because otherwise "rear recover" aborts with

Mount command 'curlftpfs ...' failed.

At least for me the backup via curlftpfs is
very much slower than the backup via NFS.

For backup via NFS "rear mkbackup" reports

Archived 916 MiB in 163 seconds [avg 5759 KiB/sec]

while in contrast for backup via curlftpfs "rear mkbackup" reports

Archived 916 MiB in 1744 seconds [avg 538 KiB/sec]

But the restore via curlftpfs is as fast as via NFS.
For restore via curlftpfs "rear recover" reports

Restored 2409 MiB in 38 seconds [avg 64942 KiB/sec]

@jsmeix jsmeix added enhancement Adaptions and new features waiting for info Also used to mark an issue as stale, cf. stale.yml labels Jun 2, 2016
@jsmeix jsmeix added this to the Rear future milestone Jun 2, 2016
@jsmeix jsmeix self-assigned this Jun 2, 2016
@jsmeix jsmeix mentioned this pull request Jun 2, 2016
Closed
@jsmeix
Copy link
Member Author

jsmeix commented Jun 2, 2016

@gdha
could you please have a look
whether or not it seems to be o.k. for you.

In particular I like that you have a look at my
"FIXME" comments in 05_check_NETFS_requirements.sh
because I think those are real (minor) bugs.

gdha
gdha reviewed Jun 3, 2016
View reviewed changes
usr/share/rear/prep/NETFS/default/05_check_NETFS_requirements.sh Outdated
fi

# include required modules, like nfs cifs ...
# FIXME: the code below includes modules for all non-empty schemes
Copy link
Member

@gdha gdha Jun 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jsmeix this must been seen as a catch all rule (as you never know what you could miss)

@jsmeix
Copy link
Member Author

jsmeix commented Jun 3, 2016

With latest commits I improved it as follows:

In global-functions.sh I ensure the fuse kernel module
is loaded for the new ftpfs BACKUP_URL because
ftpfs (via CurlFtpFS) is based on FUSE.
I simply call "modprobe fuse" when fuse in not yet loaded.
I found such kind of code at other places in rear
so that I assume it is o.k. to do it this way.

In 05_check_NETFS_requirements.sh
I soveld some FIXME issues according
to the above comments from @gdha

FYI:
Without password in the ftpfs BACKUP_URL e.g.

BACKUP_URL=ftpfs://[email protected]/rear

the password is requested multiple times.

Three times for "rear mkbackup"

# rear -d -D mkbackup
...
Using log file: /var/log/rear/rear-d26.log
Enter host password for user 'rear':
Creating disk layout
...
Creating initramfs
Enter host password for user 'rear':
Making ISO image
...
Copying resulting files to ftpfs location
Enter host password for user 'rear':
Encrypting disabled
Creating tar archive...
...
Archived 916 MiB in 1678 seconds [avg 559 KiB/sec]

Two times for "rear recover"

# rear -d -D recover
...
Using log file: /var/log/rear/rear-d26.log
insmod /lib/modules/3.12.51-60.25-default/kernel/fs/fuse/fuse.ko 
Enter host password for user 'rear':
NOTICE: Will do driver migration
...
Disk layout created.
Enter host password for user 'rear':
Decrypting disabled
Restoring from ...
...
Restored 2393 MiB in 38 seconds [avg 64490 KiB/sec]

But all in all it now works sufficiently well for me as a
"First step to support new ftpfs BACKUP_URL"
so that I think I will merge it.

@jsmeix
Copy link
Member Author

jsmeix commented Jun 3, 2016

@gdha regarding
"more complex ... if we are working with SSL certificates":

I will leave such enhancements for
"Further steps to support new ftpfs BACKUP_URL".

I think as a first step it is now good enough.

@gdha
many thanks for your valuable feedback and comments!

@jsmeix jsmeix removed the waiting for info Also used to mark an issue as stale, cf. stale.yml label Jun 3, 2016
@jsmeix jsmeix merged commit d595476 into rear:master Jun 3, 2016
@jsmeix jsmeix deleted the first_step_to_support_new_ftpfs_BACKUP_URL_issue845 branch June 3, 2016 13:50
@jsmeix jsmeix mentioned this pull request Sep 23, 2016
Closed
@jsmeix jsmeix mentioned this pull request Oct 24, 2016
Merged
@jsmeix jsmeix removed this from the ReaR 999 (future) milestone Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@gdha gdha

@jsmeix jsmeix

Labels

enhancement Adaptions and new features fixed / solved / done

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jsmeix @gdha