;).. we did (talk) years ago, when the resuming was considered new and unsafe, but it was never implemented.. ede
On 24.04.2015 16:57, Kenneth Loafman wrote:
> I could have sworn we had a --no-resume option. We probably just talked about it.
>
> ...Ken
>
>
> On Fri, Apr 24, 2015 at 8:37 AM, <address@hidden <mailto:address@hidden>> wrote:
>
> not exactly.
>
> you will not be able to resume or retry, but provided your connection is good and you can afford the traffic you'll have a one shot backend, where
> - you'll start a new backup on every run*
> - a hacked source cannot destroy/manipulate your older backups
>
> ..ede
>
> * (you will still need a way to disable resuming in duplicity)
>
> On 24.04.2015 15 <tel:24.04.2015%2015>:20, Kenneth Loafman wrote:
> > I guess that's right. If they could not overwrite, they probably could not delete either, so kinda useless as a target.
> >
> > On Fri, Apr 24, 2015 at 7:24 AM, <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>> wrote:
> >
> > ok, in conclusion that would mean that resume will build a potentially partially uploaded volume and try to upload it. if there is already a file with the same name, if only partial, the backup will fail in case it cannot overwrite mentioned file.
> >
> > that would mean the initial idea of a write once backend would require a possibility to disable resuming, which are potentially doomed to fail.
> >
> > ..ede/duply.net <http://duply.net> <http://duply.net>
> >
> > On 24.04.2015 13 <tel:24.04.2015%2013> <tel:24.04.2015%2013>:24, Kenneth Loafman wrote:
> > > No, that's not what I meant. When duplicity resumes, it looks at the manifest. If the volume is in the manifest, it's assumed to have uploaded. If not, it restarts at the next volume. Whatever volume may have been partially built (in temp space), or uploaded (partially), will be ignored.
> > >
> > > ...Ken
> > >
> > >
> > > On Fri, Apr 24, 2015 at 5:04 AM, <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>> <mailto:address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>>> wrote:
> > >
> > > so resumes only happen on local incomplete volumes? but not if an upload was interrupted?
> > >
> > > on a sidenote: retrying uploads will of course fail as well with Christian's approach.
> > >
> > > ..ede
> > >
> > > On 24.04.2015 11 <tel:24.04.2015%2011> <tel:24.04.2015%2011> <tel:24.04.2015%2011>:50, Kenneth Loafman wrote:
> > > > It would only be able to resume by rewriting and resending the incomplete volume and continuing from there. The upload part is in a temporary volume and is not saved.
> > > >
> > > > ...Ken
> > > >
> > > >
> > > > On Fri, Apr 24, 2015 at 4:00 AM, <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>> <mailto:address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>> <mailto:address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>> <mailto:address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>>>> wrote:
> > > >
> > > > On 23.04.2015 18:13, Christian Saga wrote:
> > > > > Hi there,
> > > > > I was just thinking about a new setup. Basically allowing duplicity to only write new objects to S3 and not allow deletion of old items.
> > > > > This would allow me to have the backups secured, in case the server gets hijacked.
> > > > >
> > > > > Do you know if this would pose problems with duplicity?
> > > >
> > > > it should not
> > > >
> > > > >I feel, it is only writing new objects for full and incremental backups to s3. Only the purge would delete old versions? If I would turn the purge off, then it should work?
> > > >
> > > > the purge would either fail or succeed, but in reality not have done anything depending of the implementation in the backend code. either way not an issue according to your write only strategy.
> > > >
> > > > > Or is there any other action, that would need the possibility to change files in the backend instead of just uploading?
> > > > >
> > > >
> > > > be aware of interrupted uploads. currently duplicity might try to resume a backu0p and in turn overwrite a volume on the backend, which would defeat your purpose.
> > > >
> > > > Ken: what does happen if the upload part during a resumed backup fails? would duplicity fail but try resuming again on the next run?
> > > >
> > > > ..ede/duply.net <http://duply.net> <http://duply.net> <http://duply.net> <http://duply.net>
> > > >
> > > >
> > >
> > >
> >
> > _______________________________________________
> > Duplicity-talk mailing list
> > address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>
> > https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> >
> >
> >
> >
> > _______________________________________________
> > Duplicity-talk mailing list
> > address@hidden <mailto:address@hidden>
> > https://lists.nongnu.org/mailman/listinfo/duplicity-talk
> >
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden <mailto:address@hidden>
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
>
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>
_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk