Re: restoring encrypted backups: amrecover vs amrestore
I’m pretty sure I tested an amrecover (not a whole amrestore) with my setup, where the server does the encryption. And it worked, I mean. Or I wouldn’t have continued. I might only have tested an amrecover ON the server though, and not on the client. Mine are all connected, so I guess I figured I could recover onto the server & transport later (more likely, it just didn’t occur to me to test from a client). Or maybe I did …. Let us know how your test works. Deb Baddorf On Mar 13, 2015, at 3:46 PM, Oscar Ricardo Silva wrote: > The idea behind client encryption is to treat each server/sysadmin as an > independent operator and with encryption done by the client the contents of > the tapes (or in our case, vtapes) wouldn't necessarily be accessible to the > amanda server operator. > > Ultimately, server encryption gets us a little closer. We're already > transmitting the backups over ssh so that gets us some privacy over the wire. > I'll switch over one of my test systems to "server encryption" and see how > that works. > > Thank you for the reply and the "bump" > > > > Oscar > > > On 03/13/2015 03:33 PM, Debra S Baddorf wrote: >> Since you’ve gotten no answers yet (I know very little):might this be >> related to whether the client or the server >> is the one doing the unpacking of the dump, and in turn, which one of >> those also did the encrypting? >> >> I do some encrypting on one small set of nodes, but the server does the >> encrypting. I’m merely making sure the tapes >> are encrypted so they can be stored remotely. Any reason why you have >> the client itself doing the encryption? >> I suppose it is more private that way ….. specially if the data is going >> over the network and might be seen there. >> >> This is by way of starting a discussion, and also “bump”. >> >> Deb Baddorf >> Fermilab >> >> >> On Mar 12, 2015, at 5:21 PM, Oscar Ricardo Silva wrote: >> >>> I've been testing encrypted storage of backups but am confused as to how to >>> restore files. In my setup, I run the backup server with other sysadmins >>> running the individual servers being backed up and ideally I'd like for >>> these sysadmins to restore files from the client systems without bothering >>> me ... I mean "without involving me" ... >>> >>> >>> I've had no luck restoring files using amrecover (one server encrypted with >>> amcrypt-ossl and another with amcrypt-ossl-asym) so I decided to review the >>> man page and saw: >>> >>> >>> *** >>> Note >>> The Default values are those set at compile-time. Use amrestore to recover >>> client-encrypted or client-custom-compressed tapes. >>> *** >>> >>> >>> >>> Does this mean that for the sysadmin of a client to restore files from an >>> encrypted backup, they can only use amrestore and not amrecover? amrestore >>> suggests (and I might be wrong) that the individual running it know a lot >>> about how the backups are stored. >>> >>> >>> The backups *SEEM* to run OK and using amrecover I can even browse the >>> files that were backed up. >>> >>> >>> I've reviewed the amanda HOWTOs and FAQ but while they describe the setup >>> for encrypted storage of backups, I don't believe there are examples on >>> restoring files. >>> >>> >>> >>> >>> Oscar >>
Re: restoring encrypted backups: amrecover vs amrestore
The idea behind client encryption is to treat each server/sysadmin as an independent operator and with encryption done by the client the contents of the tapes (or in our case, vtapes) wouldn't necessarily be accessible to the amanda server operator. Ultimately, server encryption gets us a little closer. We're already transmitting the backups over ssh so that gets us some privacy over the wire. I'll switch over one of my test systems to "server encryption" and see how that works. Thank you for the reply and the "bump" Oscar On 03/13/2015 03:33 PM, Debra S Baddorf wrote: Since you’ve gotten no answers yet (I know very little):might this be related to whether the client or the server is the one doing the unpacking of the dump, and in turn, which one of those also did the encrypting? I do some encrypting on one small set of nodes, but the server does the encrypting. I’m merely making sure the tapes are encrypted so they can be stored remotely. Any reason why you have the client itself doing the encryption? I suppose it is more private that way ….. specially if the data is going over the network and might be seen there. This is by way of starting a discussion, and also “bump”. Deb Baddorf Fermilab On Mar 12, 2015, at 5:21 PM, Oscar Ricardo Silva wrote: I've been testing encrypted storage of backups but am confused as to how to restore files. In my setup, I run the backup server with other sysadmins running the individual servers being backed up and ideally I'd like for these sysadmins to restore files from the client systems without bothering me ... I mean "without involving me" ... I've had no luck restoring files using amrecover (one server encrypted with amcrypt-ossl and another with amcrypt-ossl-asym) so I decided to review the man page and saw: *** Note The Default values are those set at compile-time. Use amrestore to recover client-encrypted or client-custom-compressed tapes. *** Does this mean that for the sysadmin of a client to restore files from an encrypted backup, they can only use amrestore and not amrecover? amrestore suggests (and I might be wrong) that the individual running it know a lot about how the backups are stored. The backups *SEEM* to run OK and using amrecover I can even browse the files that were backed up. I've reviewed the amanda HOWTOs and FAQ but while they describe the setup for encrypted storage of backups, I don't believe there are examples on restoring files. Oscar
Re: restoring encrypted backups: amrecover vs amrestore
Since you’ve gotten no answers yet (I know very little):might this be related to whether the client or the server is the one doing the unpacking of the dump, and in turn, which one of those also did the encrypting? I do some encrypting on one small set of nodes, but the server does the encrypting. I’m merely making sure the tapes are encrypted so they can be stored remotely. Any reason why you have the client itself doing the encryption? I suppose it is more private that way ….. specially if the data is going over the network and might be seen there. This is by way of starting a discussion, and also “bump”. Deb Baddorf Fermilab On Mar 12, 2015, at 5:21 PM, Oscar Ricardo Silva wrote: > I've been testing encrypted storage of backups but am confused as to how to > restore files. In my setup, I run the backup server with other sysadmins > running the individual servers being backed up and ideally I'd like for these > sysadmins to restore files from the client systems without bothering me ... I > mean "without involving me" ... > > > I've had no luck restoring files using amrecover (one server encrypted with > amcrypt-ossl and another with amcrypt-ossl-asym) so I decided to review the > man page and saw: > > > *** > Note > The Default values are those set at compile-time. Use amrestore to recover > client-encrypted or client-custom-compressed tapes. > *** > > > > Does this mean that for the sysadmin of a client to restore files from an > encrypted backup, they can only use amrestore and not amrecover? amrestore > suggests (and I might be wrong) that the individual running it know a lot > about how the backups are stored. > > > The backups *SEEM* to run OK and using amrecover I can even browse the files > that were backed up. > > > I've reviewed the amanda HOWTOs and FAQ but while they describe the setup for > encrypted storage of backups, I don't believe there are examples on restoring > files. > > > > > Oscar
restoring encrypted backups: amrecover vs amrestore
I've been testing encrypted storage of backups but am confused as to how to restore files. In my setup, I run the backup server with other sysadmins running the individual servers being backed up and ideally I'd like for these sysadmins to restore files from the client systems without bothering me ... I mean "without involving me" ... I've had no luck restoring files using amrecover (one server encrypted with amcrypt-ossl and another with amcrypt-ossl-asym) so I decided to review the man page and saw: *** Note The Default values are those set at compile-time. Use amrestore to recover client-encrypted or client-custom-compressed tapes. *** Does this mean that for the sysadmin of a client to restore files from an encrypted backup, they can only use amrestore and not amrecover? amrestore suggests (and I might be wrong) that the individual running it know a lot about how the backups are stored. The backups *SEEM* to run OK and using amrecover I can even browse the files that were backed up. I've reviewed the amanda HOWTOs and FAQ but while they describe the setup for encrypted storage of backups, I don't believe there are examples on restoring files. Oscar
Re: Encrypted backups on FreeBSD ?
With all the problems I've had doing client side encryption on FreeBSD I wanted to make sure amanda worked without any "fancy" options. I tried two variations on backups: 1. No compression, no encryption, ssh authentication 2. No compression, SERVER-side encryption, ssh authentication I'm happy to report that both worked and I was able to restore files successfully. It's not the end of the story. I have enough paranoid higher-ups that they just can't sleep if encryption isn't done by the client. I understand ... I might go crazy one day and have nothing better to to do than restore files for servers that I already have administrative access to ... The saga continues but it'll have to wait until I get back on Monday. Oscar
Re: Encrypted backups on FreeBSD ?
On Fri, Apr 4, 2008 at 10:31 AM, Matthew Moffitt <[EMAIL PROTECTED]> wrote: > I think an alternate informational message would help, or at least better > documentation on the requirement for using encryption. I wonder what the > client requirement check is for, perhaps it's a vestige of a previous > encryption framework? The quick answer is that amrecover has to "pass through" encryption information from amindexd and back to amidxtaped. So even though it's not doing the decryption, it needs to know about it. I can change the message, if you'll update the documentation :) Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Encrypted backups on FreeBSD ?
On 4/4/2008 4:00 AM, Dave Ewart wrote: On Thursday, 03.04.2008 at 09:29 -0400, Matthew Moffitt wrote: I've been through this but still don't have it working. On the particular disk entry (backing up with gtar) encryption doesn't run during amdump. amcheck reports the error: WARNING: testhost:/disk1/user/srl does not support server data encryption It sounds counter intuitive, but you may need to check the version of the AMANDA *client* supports "server-side" encryption. You probably need 2.5.1 or above. I was confused by this, initially, thinking "why does the client need to support encryption when I'm doing the encryption server-side?". Apparently, from reading the source code, my understanding is that AMANDA tries to figure out which facilities are supported by the client and bombs out as above in those circumstances. I'm just wondering whether this is a bug in AMANDA, or whether there is a good reason for AMANDA to insist that the client 'supports' server-side encryption ... ? Dave. Wow, that did indeed clear the error from amcheck. I haven't run amdump yet but I'm optimistic it will run now that amcheck is clearing it for encryption. I think an alternate informational message would help, or at least better documentation on the requirement for using encryption. I wonder what the client requirement check is for, perhaps it's a vestige of a previous encryption framework? -Matt
Re: Encrypted backups on FreeBSD ?
On Thursday, 03.04.2008 at 09:29 -0400, Matthew Moffitt wrote: > I've been through this but still don't have it working. On the > particular disk entry (backing up with gtar) encryption doesn't run > during amdump. amcheck reports the error: > > WARNING: testhost:/disk1/user/srl does not support server data > encryption It sounds counter intuitive, but you may need to check the version of the AMANDA *client* supports "server-side" encryption. You probably need 2.5.1 or above. I was confused by this, initially, thinking "why does the client need to support encryption when I'm doing the encryption server-side?". Apparently, from reading the source code, my understanding is that AMANDA tries to figure out which facilities are supported by the client and bombs out as above in those circumstances. I'm just wondering whether this is a bug in AMANDA, or whether there is a good reason for AMANDA to insist that the client 'supports' server-side encryption ... ? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: Encrypted backups on FreeBSD ?
I've been through this but still don't have it working. On the
particular disk entry (backing up with gtar) encryption doesn't run
during amdump. amcheck reports the error:
WARNING: testhost:/disk1/user/srl does not support server data encryption
-Matt
On 4/3/2008 3:56 AM, Dave Ewart wrote:
On Wednesday, 02.04.2008 at 16:54 -0500, Nomad wrote:
I'm having some strange issues as well, trying to do encrypted backups on
FreeBSD. Let me ask this:
1. Is encrypted storage of backups a production feature?
I got this working without too much of a problem.
1. Create a key file and a passphrase as described in 'man amcrypt',
store them in the locations indicated.
2. Use a config such as the following to perform the actual encryption:
define dumptype whatever {
# [... other settings ...]
encrypt server
server_encrypt "/usr/sbin/amcrypt"
}
Dave.
Re: Encrypted backups on FreeBSD ?
On Wednesday, 02.04.2008 at 16:54 -0500, Nomad wrote:
> I'm having some strange issues as well, trying to do encrypted backups on
> FreeBSD. Let me ask this:
>
> 1. Is encrypted storage of backups a production feature?
I got this working without too much of a problem.
1. Create a key file and a passphrase as described in 'man amcrypt',
store them in the locations indicated.
2. Use a config such as the following to perform the actual encryption:
define dumptype whatever {
# [... other settings ...]
encrypt server
server_encrypt "/usr/sbin/amcrypt"
}
Dave.
--
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
University of Oxford / Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
signature.asc
Description: Digital signature
Re: Encrypted backups on FreeBSD ?
On Wed, Apr 2, 2008 at 2:54 PM, Nomad <[EMAIL PROTECTED]> wrote: > I'm having some strange issues as well, trying to do encrypted backups on > FreeBSD. Let me ask this: > > 1. Is encrypted storage of backups a production feature? Yes. We have done limited testing on FreeBSD as well as encryption using aesutil. Most of the testing has been done using gpg. > 2. What documentation is available giving technical details on encrypted > backups using amanda? See http://www.zmanda.com/quick-backup-setup.html (uses gpg encryption) and http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption There is another amanda user who has used amcrypt (not on FreeBSD) http://forums.zmanda.com/showthread.php?t=41 Paddy
Encrypted backups on FreeBSD ?
I'm having some strange issues as well, trying to do encrypted backups on FreeBSD. Let me ask this: 1. Is encrypted storage of backups a production feature? 2. What documentation is available giving technical details on encrypted backups using amanda? What would really help is a flowchart of the path taken to encrypt and send backups I know there's a page on the zamanda wiki that talks about encryption but from reading through it there's a question whether it's a proof-of-concept or something for actual use. So far I can use ssh authentication for encrypting the transmission of backups but what I really want is to do client side encryption. There's a brief, VERY brief, piece of information on amcrypt but there's not enough information to properly configure encryption. Someone mentioned an issue with amaespipe, head and bash ... could be that's the problem. Attempting to run /usr/local/bin/amgtar by hand I get the error: head: -: No such file or directory On 4/2/08, Oscar Ricardo Silva <[EMAIL PROTECTED]> wrote: > > Sorry for the multiple recent posts but as I work my way through enabling > encrypted backups I keep running into different issues. In our last > episode, I > had enabled encrypted backups and corrected an issue with ipv6 and key > placement > on the amanda server. > > My current issue is that while backups appear to run without a hitch, I > can't > restore. These problems are all on FreeBSD machines, 4.x on up through > 6.3. I > can launch amrecover and it communicates with the amanda server. When I > try to > list files I get the error: > > No index records for disk for specified date > If date correct, notify system administrator > > I checked the amanda server and sure enough, there were no index files. > The > file for that particular filesystem was there but it was empty. I have a > feeling this isn't necessarily an amanda issue but more of a problem in how > encryption is implemented. If I try encrypting the backup file manually I > get the error: > > bz2aespipe: wrong magic - aborted > > I changed the output for amaespipe so that errors are written to a file > instead > of /dev/tty and when the backup runs I get the same error message. > > Is anybody else doing encrypted backups for FreeBSD clients? Could be we > take this off-list since it's probably not an amanda specific problem. > > > > Oscar > >
gzip wrapper script for encrypted backups and restore not working
I have setup encrypted backups using the script found at:
<http://security.uchicago.edu/tools/gpg-amanda/>
and backups appear to work. The problem comes when I attempt to restore
files using amrecover. Once the restore starts I get a message saying that
what's found is not a tar archive
Load tape daily28 now
Continue [?/Y/n/s/t]? Y
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: ./log/ldap.1: Not found in archive
tar: ./log/messages: Not found in archive
tar: Error exit delayed from previous errors
extract_list - child returned non-zero status: 2
Continue [?/Y/n/r]? n
or that it's not a dump tape:
Load tape daily28 now
Continue [?/Y/n/s/t]? Y
restore: Tape is not a dump tape
extract_list - child returned non-zero status: 1
Continue [?/Y/n/r]? Y
If I restore the entire dump or tar archive using dd off the tape then run
the gzip wrapper script, I now have a dump or a tar archive.
I've looked through the list archives and others appeared to have this same
problem but I didn't see a solution. I've changed the redirect in the
script from:
${gzip_prog} ${gzip_flags} >/tmp/amanda/gpg.debug
to
${gzip_prog} ${gzip_flags} 2>/tmp/amanda/gpg.debug
Any thoughts on what I'm doing wrong? The only thing changed in the script
is to add my gpg keys. In my dumptype I have "compress fast" turned on so
that gzip will be called.
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 28 October 2004 12:18 pm, you wrote: > Has anyone managed to get Amanda to encrypt the backups with a given > key on the client, so they are both transported & stored encrypted ? > This could likely be done after compression. > > I assume the amrestore program would have to know about this > encryption, and ask for the key when it's envoked. > > Seeing as Amanda only knows about tar and dump by default, this might > be difficult to implement, but any ideas or pointers are welcome. > > John http://security.uchicago.edu/tools/gpg-amanda/ Its been done to a point. Unfortunately, its not file by file that is encrypted but the full tarball. So if there is an error somewhere in the dump/tar you'll probably lose the whole thing if recovering. - -- Jason -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBgTAQfv0v193dIS8RAm/oAKC+od9dPeKVznIIoFkBBWVLzoS4DwCfRVAt 6KWw378TE5osSq1CTMxSVIw= =sByG -END PGP SIGNATURE-
Encrypted backups
Has anyone managed to get Amanda to encrypt the backups with a given key on the client, so they are both transported & stored encrypted ? This could likely be done after compression. I assume the amrestore program would have to know about this encryption, and ask for the key when it's envoked. Seeing as Amanda only knows about tar and dump by default, this might be difficult to implement, but any ideas or pointers are welcome. John
Re: Encrypted backups
This one time, at band camp, Andrew Hall wrote: >http://security.uchicago.edu/tools/gpg-amanda/ One of the nice things about plain tar is that it can cope with stream errors; if one block on the tape is busted then you can still recover the rest of the backup. A while ago (probably 4 months past) I started looking at this; I didnt' know about the above URL. I did some testing to see if gpg could cope with stream errors. It turns out that there's a couple of encryption algorithms that GnuPG claims to use that *can* cope with stream errors and continue decryption around it; alas I don't have any of the details anymore but it should be easy to find that out again, this time I know what I'm looking for. The problem is that you can't get GnuPG to use that algorithm (again short on details so please take large grain of salt), but OpenSSL does let you use it. I think it was the AES CBC cipher that I was looking at. I also think there was a different problem with OpenSSL that prevented it from being immediately useful. Anyway, the point I'm trying to make is that you don't want to reduce the recoverability of your tapes if you encrypt them, but I'm fairly certain that the method GnuPG uses, described at that URL above, provides no facility for recovery from stream errors. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: Encrypted backups
On Wed, Jul 28, 2004 at 01:34:59PM -0400, Andrew Hall wrote: > http://security.uchicago.edu/tools/gpg-amanda/ There is exactly one thing I don't like with this solution: it is a compile-time configuraton. My assumption is that when the Big Bang comes, my only data is my backup and the distribution CD/DVD's. Unless my distribution's rescue-CD is compiled to support this hack, I'm out of luck: I'll need to download/compile/etc/pp amanda. In the case of desaster, I'll probably _not_ have time/resources to download/compile/etc/pp amanda. Having gpg support as a runtime option (so that you can use it when booting from a rescue disk) would be a _big_ win. IMHO. -- Please visit and sign and http://www.ffii.org -- Josef Wolf -- [EMAIL PROTECTED] --
Re: Encrypted backups
> You don't have to put gzip in the pipeline. Gpg compresses data by default > (zlib level 6, according to gpg(1)), before doing encryption. Excellent. Is there an official way of encrypting amanda, or just doing it this way? Note that there is also support for using krb4 to encrypt the stream over the network, but this results in cleartext backups on the holding disk and on tape. It's also hard to set up if you don't already grok kerberos. -- Greg Troxel <[EMAIL PROTECTED]>
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 29 Jul 2004 15:27, you wrote:
> On Thu, 29 Jul 2004, Jon LaBadie wrote:
> > - the position of gzip in the pipeline was wrong in my view.
> > it came after encryption meaning it was working on somewhat
> > randomized data. Thus the compression would likely be small.
>
> You don't have to put gzip in the pipeline. Gpg compresses data by default
> (zlib level 6, according to gpg(1)), before doing encryption.
Excellent. Is there an official way of encrypting amanda, or just doing it
this way?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [EMAIL PROTECTED]
>
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that. -- Linus Torvalds
- --
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 587369
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E [EMAIL PROTECTED]
Open Source. Open Solutions.
http://www.suretecsystems.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBCQ9QeWseh9tzvqgRAveyAJ0QOgmbteprPFoCSZV2/hca2zm3qQCfefi2
b25SjgmJgOmbsTilzNw3ddI=
=jOaX
-END PGP SIGNATURE-
Re: Encrypted backups
On Thu, 29 Jul 2004, Jon LaBadie wrote:
> - the position of gzip in the pipeline was wrong in my view.
> it came after encryption meaning it was working on somewhat
> randomized data. Thus the compression would likely be small.
You don't have to put gzip in the pipeline. Gpg compresses data by default
(zlib level 6, according to gpg(1)), before doing encryption.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: Encrypted backups
On Thu, Jul 29, 2004 at 10:03:22AM +0100, Gavin Henry wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wednesday 28 Jul 2004 18:34, you wrote: > > Gavin, > > > > I set this up a few years back and it rocked! > > > > http://security.uchicago.edu/tools/gpg-amanda/ > > Thanks, I've had a read. How much does this slow down the backup? I take it > clients need to do client side compression in order for nothing to be sent > clear text across the wire? > > > > > On Wed, 2004-07-28 at 13:18, Gavin Henry wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Hi all, > > > > > > Has this been discussed before? > > > > > > I was thinking of using a encrypted filesystems for the tmp storage, then > > > dumping that to tape? > > > It has been a while since I read that document so my memory may be imperfect. Two things I seem to recall: - compression is optional, just like in amanda in general - the position of gzip in the pipeline was wrong in my view. it came after encryption meaning it was working on somewhat randomized data. Thus the compression would likely be small. But recall, I've never used the system, just impressions from reading. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 29 Jul 2004 09:20, you wrote: > On Wednesday, 28.07.2004 at 13:34 -0400, Andrew Hall wrote: > > > Hi all, > > > > > > Has this been discussed before? > > > > > > I was thinking of using a encrypted filesystems for the tmp storage, > > > then dumping that to tape? > > > > I set this up a few years back and it rocked! > > > > http://security.uchicago.edu/tools/gpg-amanda/ > > Just make sure that you keep your GPG keys backed up *separately* :-) :-) > > Dave. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E [EMAIL PROTECTED] Open Source. Open Solutions. http://www.suretecsystems.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCL1qeWseh9tzvqgRApojAJ9oM67P/hxYKORGhpeo9ZQ48j5HPACfW/Wb /FAliNRv4ksPo+UEronupqQ= =n97C -END PGP SIGNATURE-
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 28 Jul 2004 18:34, you wrote: > Gavin, > > I set this up a few years back and it rocked! > > http://security.uchicago.edu/tools/gpg-amanda/ Thanks, I've had a read. How much does this slow down the backup? I take it clients need to do client side compression in order for nothing to be sent clear text across the wire? > > Drew > > On Wed, 2004-07-28 at 13:18, Gavin Henry wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi all, > > > > Has this been discussed before? > > > > I was thinking of using a encrypted filesystems for the tmp storage, then > > dumping that to tape? > > > > Gavin. > > > > - -- > > Kind Regards, > > > > Gavin Henry. > > Managing Director. > > > > T +44 (0) 1224 587369 > > M +44 (0) 7930 323266 > > F +44 (0) 1224 742001 > > E [EMAIL PROTECTED] > > > > Open Source. Open Solutions. > > > > http://www.suretecsystems.com/ > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.2.4 (GNU/Linux) > > > > iD8DBQFBB9/6eWseh9tzvqgRArMCAKCU1CGYGVGxvzwuTWbJBRsUR46A6QCeJItu > > hXZvPIfcLzGmpEDGCh7Ihnw= > > =nW8r > > -END PGP SIGNATURE- - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E [EMAIL PROTECTED] Open Source. Open Solutions. http://www.suretecsystems.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCL1aeWseh9tzvqgRAjo0AJ0V5yywWZ3NDMdZbQQIRj8IeXpkeQCgnWyt SDpDaQ7BQmLpU8eZ2OO107o= =3Eri -END PGP SIGNATURE-
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 28.07.2004 at 13:34 -0400, Andrew Hall wrote: > > Hi all, > > > > Has this been discussed before? > > > > I was thinking of using a encrypted filesystems for the tmp storage, > > then dumping that to tape? > > I set this up a few years back and it rocked! > > http://security.uchicago.edu/tools/gpg-amanda/ Just make sure that you keep your GPG keys backed up *separately* :-) Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCLNabpQs/WlN43ARAiR2AKDQ+aEXUhSUST+/rfsWcxxJrjfpMgCfSaQh j4jj01uLzL50on0Vt0eWJuM= =wZor -END PGP SIGNATURE-
Re: Encrypted backups
Gavin, I set this up a few years back and it rocked! http://security.uchicago.edu/tools/gpg-amanda/ Drew On Wed, 2004-07-28 at 13:18, Gavin Henry wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Has this been discussed before? > > I was thinking of using a encrypted filesystems for the tmp storage, then > dumping that to tape? > > Gavin. > > - -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 587369 > M +44 (0) 7930 323266 > F +44 (0) 1224 742001 > E [EMAIL PROTECTED] > > Open Source. Open Solutions. > > http://www.suretecsystems.com/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFBB9/6eWseh9tzvqgRArMCAKCU1CGYGVGxvzwuTWbJBRsUR46A6QCeJItu > hXZvPIfcLzGmpEDGCh7Ihnw= > =nW8r > -END PGP SIGNATURE- >
Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Has this been discussed before? I was thinking of using a encrypted filesystems for the tmp storage, then dumping that to tape? Gavin. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E [EMAIL PROTECTED] Open Source. Open Solutions. http://www.suretecsystems.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBB9/6eWseh9tzvqgRArMCAKCU1CGYGVGxvzwuTWbJBRsUR46A6QCeJItu hXZvPIfcLzGmpEDGCh7Ihnw= =nW8r -END PGP SIGNATURE-
