From owner-freebsd-geom@FreeBSD.ORG Sun Mar 4 21:05:52 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB517106564A for ; Sun, 4 Mar 2012 21:05:52 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC968FC14 for ; Sun, 4 Mar 2012 21:05:52 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1916231vcm.13 for ; Sun, 04 Mar 2012 13:05:51 -0800 (PST) Received-SPF: pass (google.com: domain of rsimmons0@gmail.com designates 10.52.23.74 as permitted sender) client-ip=10.52.23.74; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rsimmons0@gmail.com designates 10.52.23.74 as permitted sender) smtp.mail=rsimmons0@gmail.com; dkim=pass header.i=rsimmons0@gmail.com Received: from mr.google.com ([10.52.23.74]) by 10.52.23.74 with SMTP id k10mr30497160vdf.106.1330895151721 (num_hops = 1); Sun, 04 Mar 2012 13:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mS360t+KzMEKJ5lldGb4BOPSYu6hZ7sDjnHspGpC9tQ=; b=xxF++zBm9oOXhpggZVIdMGs+KNz+6RpV+sDKuNCulh0sDGW1FXrLwzV3PMzZ0HAgwB WlZsfpfozgWZONBAStVz7kMao6b3NXRp19YxStN4Xvl/mdIk49eQJNC7VUXZGK5n/vRW 6vJDGljZtthESYBECPc/VR3yai3ni6N0KKbhM4tTxzPT0SSYBZDHDuhCFyBaE4l5ju4P TVb0UDjl897kBc8ToN1mG7V+S7ryKNj2oy9SnmxLVrxl1jl1YZ/YCHWplY4hgbnFtgn2 YotPmw+kZFLogH2HF6NEU2B+qpNRhGN5mPVXjrQjw0LFBwgiegKfJ6QVPNnYK6NdpLsB pMVw== MIME-Version: 1.0 Received: by 10.52.23.74 with SMTP id k10mr26112620vdf.106.1330895151678; Sun, 04 Mar 2012 13:05:51 -0800 (PST) Received: by 10.52.65.114 with HTTP; Sun, 4 Mar 2012 13:05:51 -0800 (PST) In-Reply-To: <20120302131429.183b491d@gumby.homeunix.com> References: <20120302131429.183b491d@gumby.homeunix.com> Date: Sun, 4 Mar 2012 16:05:51 -0500 Message-ID: From: Robert Simmons To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: geli init for first time X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:05:52 -0000 On Fri, Mar 2, 2012 at 8:14 AM, RW wrote: > On Thu, 1 Mar 2012 22:00:17 -0500 > Robert Simmons wrote: > >> After you perform "geli init" and "geli attach" you must use dd to >> initialize the new provider before you run newfs. =A0If you had enabled >> authentication of some kind during the init step, when you attach the >> provider you get a series of errors such as these: >> GEOM_ELI: ada0p4.eli: 4096 bytes corrupted at offset 0. >> GEOM_ELI: ada0p4.eli: 4096 bytes corrupted at offset 4096. >> >> ... >> I propose that a switch be added to "geli attach" that signifies that >> it is the first time that a provider is being attached and these >> errors are to be suppressed. > > > If you know to use the switch then you'd know that the warnings are > harmless. Perhaps it would be better to make the warning more accurate: > > GEOM_ELI: ada0p4.eli: 4096 bytes not authenticated at offset 4096. > > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... add something= to the end of the DATA >> AUTHENTICATION section of the geli(8) man page that mentions why these >> errors occur and that they can be safely ignored. > > Good idea I have created a patch that incorporates the change in error messages that you suggested to make them more accurate as well as add a bit of information about these error messages to the geli(8) man page. I submitted this patch in the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D165695 From owner-freebsd-geom@FreeBSD.ORG Mon Mar 5 06:01:51 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF8A106566C for ; Mon, 5 Mar 2012 06:01:51 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id EFB578FC0A for ; Mon, 5 Mar 2012 06:01:50 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so2232254wib.13 for ; Sun, 04 Mar 2012 22:01:44 -0800 (PST) Received-SPF: pass (google.com: domain of juli@clockworksquid.com designates 10.180.103.35 as permitted sender) client-ip=10.180.103.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juli@clockworksquid.com designates 10.180.103.35 as permitted sender) smtp.mail=juli@clockworksquid.com Received: from mr.google.com ([10.180.103.35]) by 10.180.103.35 with SMTP id ft3mr12609432wib.0.1330927304183 (num_hops = 1); Sun, 04 Mar 2012 22:01:44 -0800 (PST) Received: by 10.180.103.35 with SMTP id ft3mr9934721wib.0.1330925567288; Sun, 04 Mar 2012 21:32:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.209.78 with HTTP; Sun, 4 Mar 2012 21:32:27 -0800 (PST) From: Juli Mallett Date: Sun, 4 Mar 2012 21:32:27 -0800 Message-ID: To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmwcdKKuT1Yxg/D6gqOFF+YbZWlr01n89t8+bRG+2J8UAQF1TB3qAlcjnjtH1WzZV6i4WYV Cc: Nathan Whitehorn Subject: libgeom's use of kernel pointer identifiers / proper internalization of opaque strings X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 06:01:51 -0000 Hey folks, libgeom assumes that the id and ref parameters from the kernel can be represented as userland pointers. This is certainly handy in terms of making the pointer substitution that occurs straightforward, but it breaks running a 32-bit libgeom on a 64-bit kernel where the first 32-bits of the kernel pointers are identical and non-zero. It seems to me that using strtoumax and uintmax_t for the opaque identifiers and making the pointers separate fields will give better behavior in general (no crashes on unresolved references in the kernel due to someone forgetting to properly declare a class) and also fix this problem. If that is undesirable, then using gident to do internalization on the fly either using strtoumax or using the strings directly might be better. Here's a rough cut of using the strings to do internalization which I've tested and believe can be committed. If anyone feels like reviewing it or suggesting a better fix to libgeom, I'd be happy to hear it. http://people.freebsd.org/~jmallett/internalize-libgeom-ids.diff CCing Nathan W. who does not see this problem on PowerPC64, but I suspect could under the right circumstances. Thanks, Juli. PS: Please CC me as I am not subscribed to the list. And if you think the patch is great, just commit me. I don't really want to touch libgeom. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 5 11:07:07 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71181065694 for ; Mon, 5 Mar 2012 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BFFC8FC0A for ; Mon, 5 Mar 2012 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q25B77iU034853 for ; Mon, 5 Mar 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q25B76sv034851 for freebsd-geom@FreeBSD.org; Mon, 5 Mar 2012 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2012 11:07:06 GMT Message-Id: <201203051107.q25B76sv034851@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 71 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 5 12:52:40 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 346F91065672 for ; Mon, 5 Mar 2012 12:52:40 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B59048FC1B for ; Mon, 5 Mar 2012 12:52:39 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so2508083wib.13 for ; Mon, 05 Mar 2012 04:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=auVTu4afjFhTJqqvwmQDkLcOYuzgwy3aHBgFERv9Rlw=; b=H2moTI1VXSHzQCrI/v3jQCkPuyln0/KLephYmRxMO5vH7McCGwz28f6j19qdqq9Nfa +qeNu2kBTpFCpgqKhXx1QQ7zs/ais98L/6RH9u4paF+DznyYOy7oPz/gxGp+ZVnvxcOK CaF/A2V3luYv/5OpSQ782vnKtXuwlJqrhjNWIONA35+a2G77xNvsjKfrhUrnhTT3fSgf s8KyVfAYWEZ9KQQEtEoYcaeO6w1DQ/Uv8oKgj3B0KQxnqYBlWRAfSljFk6Aeeo/AkE2b 8h7zEG7dZgR61uromo0xMh9hG+ZuXl4uGeH20ipnDy4cSLHMJ8GQj5jzcGOmnT5QL5ID 6rlA== Received: by 10.180.100.196 with SMTP id fa4mr13914275wib.0.1330951958606; Mon, 05 Mar 2012 04:52:38 -0800 (PST) Received: from gumby.homeunix.com (87-194-105-247.bethere.co.uk. [87.194.105.247]) by mx.google.com with ESMTPS id r8sm35902433wiw.10.2012.03.05.04.52.32 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 04:52:33 -0800 (PST) Date: Mon, 5 Mar 2012 12:52:31 +0000 From: RW To: freebsd-geom@freebsd.org Message-ID: <20120305125231.275bfb23@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: geli metadata backup X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 12:52:40 -0000 On Sat, 3 Mar 2012 17:24:15 -0500 Robert Simmons wrote: > What exactly is contained in the metadata backup > file /var/backups/_prov_.eli ? I don't know exactly what's in the metadata, but the most important thing is that it contains copies of the master key encrypted with the user keys. If the metadata sector on the partition is corrupted then you can't access your data. > Obviously, since I keep /var inside of the encrypted provider, the > default location is a bad place for a backup. Where would a good > location be to save this metadata using the -B switch for geli init > other than the default? Anywhere you like except inside the volume it backs-up - preferably offline. It is also somewhat sensitive. If someone else has the metadata and the passphrase/keyfile, then changing or deleting the key on disk wont help - you would have to dump the data and create a new geli partition. From owner-freebsd-geom@FreeBSD.ORG Mon Mar 5 15:37:13 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B33851065674 for ; Mon, 5 Mar 2012 15:37:13 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 645418FC08 for ; Mon, 5 Mar 2012 15:37:13 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2682780vcm.13 for ; Mon, 05 Mar 2012 07:37:12 -0800 (PST) Received-SPF: pass (google.com: domain of rsimmons0@gmail.com designates 10.52.23.169 as permitted sender) client-ip=10.52.23.169; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rsimmons0@gmail.com designates 10.52.23.169 as permitted sender) smtp.mail=rsimmons0@gmail.com; dkim=pass header.i=rsimmons0@gmail.com Received: from mr.google.com ([10.52.23.169]) by 10.52.23.169 with SMTP id n9mr35733460vdf.15.1330961832889 (num_hops = 1); Mon, 05 Mar 2012 07:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hKEDobow7C3Kk7QvX2k7s0S6QJe+5QuD+Pe9hVPdXSo=; b=V/AWJUOoQRgjfnRXG88ThMZR7LXWHO9ySmELS5OxXTBUJeJIWYAaNeswJKE7Jp5w4V 8BtESEdniqfUmOwWEQHdFCIbXCXDrNVY/EcYW7JCV8wkY5Xq4WelIHezOQUYsz4zPBHC Dt2JX9pyL6WImJWdByTRSKmnCUKiSzzuWT+5EUIFTnR81oIPMI6aw8pZ1QCLz3wg3V9z kFYdwHKR4tCLU9K1ISbkqZ1SmmFyc2keZZvidGg9fSn+yZSB2h/uAsek4aPtraQwBOqX 6SdcbOmlLMmi2Xbl8wOTPtuT1fJL9Eywg3l8VOIJWNziNo0Lt0/N/Ykg9P61gGo7aO+e oe+w== MIME-Version: 1.0 Received: by 10.52.23.169 with SMTP id n9mr30570126vdf.15.1330961832846; Mon, 05 Mar 2012 07:37:12 -0800 (PST) Received: by 10.52.65.114 with HTTP; Mon, 5 Mar 2012 07:37:12 -0800 (PST) In-Reply-To: <20120305125231.275bfb23@gumby.homeunix.com> References: <20120305125231.275bfb23@gumby.homeunix.com> Date: Mon, 5 Mar 2012 10:37:12 -0500 Message-ID: From: Robert Simmons To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: geli metadata backup X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:37:13 -0000 On Mon, Mar 5, 2012 at 7:52 AM, RW wrote: > On Sat, 3 Mar 2012 17:24:15 -0500 > Robert Simmons wrote: > >> What exactly is contained in the metadata backup >> file /var/backups/_prov_.eli ? > > I don't know exactly what's in the metadata, but the most important > thing is that it contains copies of the master key encrypted =A0with the > user keys. If the metadata sector on the partition is corrupted then > you can't access your data. As far as I can tell, the metadata backup is made when the provider is created. It is only updated when the keys/passphrases change or if the volume size is changed. It doesn't have a component that is updated constantly, correct? > >> Obviously, since I keep /var inside of the encrypted provider, the >> default location is a bad place for a backup. =A0Where would a good >> location be to save this metadata using the -B switch for geli init >> other than the default? > > Anywhere you like except inside the volume it backs-up - preferably > offline. It is also somewhat sensitive. If someone else has the > metadata and the passphrase/keyfile, then changing or deleting the key > on disk wont help - you would have to dump the data and create a new > geli partition. I gather that the best thing to do would be to write this backup file to a USB key when the provider is created then store that somewhere safe with maybe another copy burned to a CD for added safety, correct?