FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 04-17-2008, 07:49 PM
Chris Walters
 
Default Encrypted backups under Gentoo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jan Seeger wrote:
| At Thu, 17 Apr 2008 14:37:52 -0400,
| Chris Walters wrote:
<snip>
| This sounds like a feasible solution, I will try it out. Thanks for
| the idea, Florian and Chris.
|
| I'm just wondering what the dar64 and dar32 useflags do...

As I understand it, dar32 uses 32 bit integers and dar64 uses 64 bit integers,
I believe to represent file and archive sizes. The description on the the USE
flag dar64 on the Gentoo site says, "Enables --enable-mode=64 option, which
replace infinint by 64 bits integers." The dar32 option is described in the
same way, only with 32 replacing 64.

Regards,
Chris
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJIB6nGAAoJEIAhA8M9p9DAfPMP/RsttxEQmsX1EF0Ztilhkxox
dRHX+h5A723LGDgs0eDCG32qn+PMFpFzpRaYlT6k/zk82QwVXcBzDaPse9/REzch
eze1sItugrts5tB+j8VosNC9w7EvtvHq4R3cD56OoJ4xz0C7yw dUQvO2eTUJ7z8s
QklhRcY3flb4UIiVD/RmcB7TjY5mnJ9y4HqYq1pjgZxeAGWztJlXnQQbcO1tFST8
x8C2rgkT8A9LcyNm/leyQHmU6leys9flGWrr6q4g26Qvf9dPimPn0BnbPROmGEhJ
+eF3UFqR/ir4+JSeiDFzS0XuPN3id3C3n90qWawPeWEbmCnGazAepvH/P68hkPRV
bSb9ehhLwE2OjsiQg66zWKB3ZnVYKK+8MglddZUtGfAKVhxr53 gbqhVolzZ0cE5a
pLbAz9zPoMfkQewQJux+ECoAwFRuOeV29wRXDuvb4sxTWN/Z3rvPFDvPgPjBClK1
uV1gKFRfE93N6NBAPkJHF8UlBjVN+LY4kqWmgFMjU3SnRBkw1H jwLMeaWh3qGdkC
R39i3GvE57M8X6YXOyFf2WtxDRzzLcyv/a1DvkVbr0uGVZAjkePgnldzCj5snoIw
+xY+3H9Y0MydrjuohdlrWj0davI+tG0lfM/FuV3e7Zl/zxYHr8QFWzYx8hgf3UUJ
+Om6MbxFsyo59mxF56W5
=758z
-----END PGP SIGNATURE-----
--
gentoo-user@lists.gentoo.org mailing list
 
Old 04-17-2008, 08:36 PM
Neil Bothwick
 
Default Encrypted backups under Gentoo

On Thu, 17 Apr 2008 20:57:47 +0200, Remy Blank wrote:

> > I'm now testing app-backup/boxbackup,
> > which seems good so far.
>
> Please report your findings on the list! I'm not all too happy about my
> current solution (rdiff-backup locally to a filesystem over dmcrypt,
> loopback-mounted from a file, followed by an rsync over ssh to a remote
> host), and I'd be happy to find something better!

I'm currently using it with a local server. If I decide to use the
backups on a remote server too, I'll probably stick to backing up to the
local server and then using rsync. It makes sense to have a copy of the
backup locally and only use the much slower option of restoring from a
remote host when absolutely necessary.


--
Neil Bothwick

Top Oxymorons Number 36: Alone together
 
Old 04-18-2008, 06:08 AM
Florian Philipp
 
Default Encrypted backups under Gentoo

On Thu, 2008-04-17 at 20:05 +0200, Jan Seeger wrote:
> At Thu, 17 Apr 2008 19:16:54 +0200,
> Florian Philipp wrote:
> > I personally use dar and gpg. Dar can be used to make incremental
> > backups which should partly solve your speed problem. Alternatively you
> > could use tar and gpg or cpio or whatever floats your boat.
>
> Duplicity also does incremental backups, but it's still slow. Using
> dar, would I have to "manually" (or per script) use gpg to encrypt the archives?

I use GPG instead of DAR's build-in encryption because asymmetric
encryption allows complete automation of the backup process, e.g. you
don't have to store the key as a plaintext file or type it at every
backup.

And yes, you need a custom script. For incremental backups to work you
would need to make an "isolated catalogue" (dar's nomenclature) in order
for it to see which files and timestamps are already backuped without
decrypting the archive. Tar uses a similar approach.

>
> > The alternative would be an encrypted filesystem and rdiff-backup or
> > rsync. Optionally you could safe the key to the filesystem on your home
> > partition or, if it doesn't need to be automated, in a gpg-encrypted
> > file.
>
> An encryted filesystem and rdiff-backup or similar was another option
> I though of. The problem is restoration: Would I easily be able to
> restore the backups from a freshly installed system?

AFAIK cryptsetup is part of Gentoo's stage3. Most live-CD's I've tried
had support for it, too. Commonly they also offer all common encryption
modules for the kernel and GPG, so I wouldn't worry about this. Just
make sure to keep your key and everything you need to decrypt off site.
I myself store my GPG-key on a server, my parent's PC and my USB-stick.

Since rdiff-backup stores all its internal data in a single directory,
(.rdiff-backup, I think) you could still access the last snapshot of
your system even without the program itself.
 
Old 04-18-2008, 07:34 AM
Remy Blank
 
Default Encrypted backups under Gentoo

Neil Bothwick wrote:

I'm currently using it with a local server. If I decide to use the
backups on a remote server too, I'll probably stick to backing up to the
local server and then using rsync. It makes sense to have a copy of the
backup locally and only use the much slower option of restoring from a
remote host when absolutely necessary.


There are at least two drawbacks to using rsync for mirroring the local
backup to a remote host:


- If your local backup becomes corrupt, then so does your remote
backup, except if you are quick enough to disable the rsync step.


- If you have disconnection during the rsync step (happened to me last
night), your remote backup is temporarily corrupted.


For the second problem, I'm toying with the idea of writing an
rsync-like tool for mirroring one big file to a remote server, by first
transmitting the changes and storing them separately on the remote
machine, then performing the update on the big file after the connection
has closed.


-- Remy
 
Old 04-18-2008, 08:26 AM
Neil Bothwick
 
Default Encrypted backups under Gentoo

On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote:

> There are at least two drawbacks to using rsync for mirroring the local
> backup to a remote host:
>
> - If your local backup becomes corrupt, then so does your remote
> backup, except if you are quick enough to disable the rsync step.

That's a potential problem with any form of backup, local or remote. The
truly paranoid would use two different backup methods on two physically
separate destinations.

> - If you have disconnection during the rsync step (happened to me
> last night), your remote backup is temporarily corrupted.

That should be fixable by having the script that runs rsync check the
return value and try again if it fails.


--
Neil Bothwick

The original point and click interface was a Smith & Wesson.
 
Old 04-18-2008, 08:44 AM
Florian Philipp
 
Default Encrypted backups under Gentoo

On Fri, 2008-04-18 at 09:34 +0200, Remy Blank wrote:
> Neil Bothwick wrote:
> > I'm currently using it with a local server. If I decide to use the
> > backups on a remote server too, I'll probably stick to backing up to the
> > local server and then using rsync. It makes sense to have a copy of the
> > backup locally and only use the much slower option of restoring from a
> > remote host when absolutely necessary.
>
> There are at least two drawbacks to using rsync for mirroring the local
> backup to a remote host:
>
> - If your local backup becomes corrupt, then so does your remote
> backup, except if you are quick enough to disable the rsync step.

That's why I use rdiff-backup.
>
> - If you have disconnection during the rsync step (happened to me last
> night), your remote backup is temporarily corrupted.
> For the second problem, I'm toying with the idea of writing an
> rsync-like tool for mirroring one big file to a remote server, by first
> transmitting the changes and storing them separately on the remote
> machine, then performing the update on the big file after the connection
> has closed.

Shouldn't rsync do this on its own? There is an option --inplace
described with:

"This causes rsync not to create a new copy of the file and then move it
into place. Instead rsync will overwrite the existing file,
meaning that the rsync algorithm can't accomplish the full amount of
network reduction it might be able to otherwise (since it does not yet
try to sort data matches). One exception to this is if you combine the
option with --backup, since rsync is smart enough to use the backup
file as the basis file for the transfer.
This option is useful for transfer of large files with block-based
changes or appended data, and also on systems that are disk bound, not
network bound.

The option implies --partial (since an interrupted transfer does not
delete the file), but conflicts with --partial-dir and --delay-updates.
Prior to rsync 2.6.4 --inplace was also incompatible with --compare-dest
and --link-dest.

WARNING: The file's data will be in an inconsistent state during the
transfer (and possibly afterward if the transfer gets interrupted), so
you should not use this option to update files that are in use. Also
note that rsync will be unable to update a file in-place that is not
writable by the receiving user."
 
Old 04-18-2008, 08:54 AM
Neil Bothwick
 
Default Encrypted backups under Gentoo

On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote:

> > - If your local backup becomes corrupt, then so does your remote
> > backup, except if you are quick enough to disable the rsync step.
>
> That's why I use rdiff-backup.

rdiff-backup isn't really suitable for offsite backups because it uses no
compression, making the space and bandwidth requirements double those of
other methods. It also uses no encryption.

Duplicity is by the same author and is aimed more at offsite backups.


--
Neil Bothwick

Windows Error:01F Reserved for future mistakes.
 
Old 04-18-2008, 08:57 AM
John covici
 
Default Encrypted backups under Gentoo

on Friday 04/18/2008 Neil Bothwick(neil@digimed.co.uk) wrote
> On Fri, 18 Apr 2008 09:34:49 +0200, Remy Blank wrote:
>
> > There are at least two drawbacks to using rsync for mirroring the local
> > backup to a remote host:
> >
> > - If your local backup becomes corrupt, then so does your remote
> > backup, except if you are quick enough to disable the rsync step.
>
> That's a potential problem with any form of backup, local or remote. The
> truly paranoid would use two different backup methods on two physically
> separate destinations.
>
> > - If you have disconnection during the rsync step (happened to me
> > last night), your remote backup is temporarily corrupted.
>
> That should be fixable by having the script that runs rsync check the
> return value and try again if it fails.

Would not these problems be solved by something like rdiff-backup
which I have been using for a short time. Its not encrypted, however
and I am not sure what happened to the developer, but it does seem to
work.

--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?

John Covici
covici@ccs.covici.com
--
gentoo-user@lists.gentoo.org mailing list
 
Old 04-18-2008, 10:06 AM
Florian Philipp
 
Default Encrypted backups under Gentoo

On Fri, 2008-04-18 at 09:54 +0100, Neil Bothwick wrote:
> On Fri, 18 Apr 2008 10:44:05 +0200, Florian Philipp wrote:
>
> > > - If your local backup becomes corrupt, then so does your remote
> > > backup, except if you are quick enough to disable the rsync step.
> >
> > That's why I use rdiff-backup.
>
> rdiff-backup isn't really suitable for offsite backups because it uses no
> compression, making the space and bandwidth requirements double those of
> other methods. It also uses no encryption.

It uses compression (gzip), but only for increments.
 
Old 04-18-2008, 10:31 AM
Neil Bothwick
 
Default Encrypted backups under Gentoo

On Fri, 18 Apr 2008 12:06:39 +0200, Florian Philipp wrote:

> > rdiff-backup isn't really suitable for offsite backups because it
> > uses no compression, making the space and bandwidth requirements
> > double those of other methods. It also uses no encryption.
>
> It uses compression (gzip), but only for increments.

Exactly, the current data backed up is as on the original filesystem,
unencrypted and uncompressed. This does make for incredibly easy
restoration, needing only cp, but isn't really suitable for offsite use.
Duplicity is better in this respect, but uses excessive amounts of
bandwidth.


--
Neil Bothwick

What did the first man to discover you can get milk from cows think he
was doing? - anon.
 

Thread Tools




All times are GMT. The time now is 06:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org