On Tue, Dec 14, 2010 at 4:15 AM,
<address@hidden> wrote:
On 14.12.2010 00:58,
address@hidden wrote:
Thanks for the insight, edgar.
What do you mean by backend? I've never heard the term used with regard to
duplicity.
Please remember in case errors. Usually we need the full command line run debug verbosity and it's output. In case of duply the duplicity command line is generated so you would have to run duply with the --preview option to show us command line duplicity was run with.
And again, do not forget to obfuscate :)
ede/duply.net
I will be restarting my backups from scratch today (for a different reason),
but I will definitely submit a bug report if I it returns after the second
full backup. I really appreciate the interest in resolving the bug.
Thank you also for the note about private data. I will be sure to remember
that.
On Mon, Dec 13, 2010 at 5:37 AM,<address@hidden> wrote:
Smells like something is fishy in ssh backend or in the routines
interpreting the archive-dir/name parameter.
@sivewkirmi: Which backend are you using?
Could one of you please file a bug report on launchpad? Could you please
state your duplicity and python versions, 32bit or 64bit and add the output
of a test case like mentioned below with '--verbosity debug' as parameter.
Check the ouput for private data and obfuscate it.
If you are using duply. Just create a test profile and add the '--verbosity
debug' parameter on every run.
ede/duply.net
On 12.12.2010 19:51, address@hidden wrote:
It doesn't look like I changed between versions right between full and
incr,
but I was changing versions a few days before full.
On 2010-11-21, I upgraded from 1.5.2.3 to 1.5.4. On 2010-11-25, I reverted
back to 1.5.2.3. Full was run on 2010-11-29 and the next attempt at
incremental failed due to the error described.
On Sun, Dec 12, 2010 at 6:56 AM,<address@hidden> wrote:
Did you change duply versions between full and incr? From which to which?
Changelog for 1.5.2 states
# - added --name=duply_<profile> for duplicity 0.6.01+ to name cache
folder
ede/duply.net
On 11.12.2010 23:08, address@hidden wrote:
That does make sense.
The source and destination have not changed, so something else must
have.
My
suspicion is that duply might have messed something up. I recently tried
using duply 1.5.4 (I've since reverted back to 1.5.2.3), but it gave me
somewhat strange errors related to my GPG keys and refused to back
anything
up. Maybe that somehow caused duplicity to become confused?
I guess the solution would be to use "--allow-source-mismatch" once to
correct this problem. Is that correct?
Thanks for all of the help.
John
On Sat, Dec 11, 2010 at 5:02 PM, Jeremy Miller<address@hidden>
wrote:
I actually run all my backups with the "--allow-source-mismatch"
switch. With the massive amount of backups I take I do not have time
to recreate everything sometimes if one of the backups servers fail
and metadata is lost. After restoring, sometimes it doesn't realize
it's the "same" dataset and thinks by default duplicity won't
overwrite and existing backup with the same name. Have you
reinstalled or changed your GPG keys? Some change has occurred and
the backup location and the backup source are no longer synced and
they do not know they are "related" anymore. I hope that makes sense.
Jeremy
On Sat, Dec 11, 2010 at 4:52 PM, address@hidden
<address@hidden> wrote:
I am using duply + duplicity to backup my local machine.
The last backup I ran was a full backup (the second full backup to my
backup
directory). Today I am trying to run an incremental backup, but
receive
this
error instead:
"Aborting because you may have accidentally tried to backup two
different
data sets to the same remote location, or using the same archive
directory.
If this is not a mistake, use the --allow-source-mismatch switch to
avoid
seeing this message."
Does anybody know what this is about? I read the manual but am still a
bit
confused on what I am doing wrong.
Thanks in advance.
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
--
Jeremy Miller
Head of Virtualization
Site5.com LLC
www.site5.com
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk