Note, that to do this, you need to have unencryption locally on
the server. Duplicity assumes an insecure server model. To
collapse incremental backups onto a full backup means that all your
data is compromised to the level of security of the remote server.
The duplicity model assumes that once the data goes out over the
wire it is subject to unknown security.
For any commercial remote storage, you might as well just use a
commercial backup system without encryption.
-Scott
On Apr 15, 2015, at 07:21, address@hidden wrote:
On 15.04.2015 12:56, Ulrik Rasmussen wrote:
On Wed, 15 Apr 2015 12:00:00 +0200 address@hidden wrote:
On 15.04.2015 09:54, Ulrik Rasmussen wrote:
Hi,
I just started using duplicity for backing up my work to a
VPS. It is my understanding that it is wise to do a full
backup about once a month, to enable deletion of old
backups and faster restoration. However, when doing a full
backup, duplicity seems to transfer everything over the
wire again, which takes a long time if I'm on a slow
connection and also costs me bandwidth. Since the server
already has all my data, this really shouldn't be
necessary.
Is there a way to do a full backup on the server side? More
precisely, can I tell duplicity to create a new backup
chain based on the contents of the current chain?
no.
duplicity deals with "dumb" backends and solely uses them
for file storage. for this design to create a synthetic full
you would have to transfer the whole data over the line
again anyway completely.
however, it'd be possible to implement that for the rare
cases that users have shell access to their backends and can
have a duplicity instance running locally there.
see also
https://answers.launchpad.net/duplicity/+question/257348
..ede/duply.net
I see, thanks for clarifying. That makes sense, considering
most backends don't imply shell access. Since I _do_ have
shell access to the server and plenty of disk storage, I guess
I can accomplish the task by just restoring the incremental
backup on the server and doing a full backup from that using
the file system backend.
right you are.. make sure to have identical users/numeric ids
and restore as root, if you want to keep those.
alternatively you can hackishly "reuse" the old full by copying
it and updating the filenames with a proper newer timestamp.
depending on your data's turnover you might be doing that for a
while until your first incremental grows too big.
..ede/duply.net
_______________________________________________ 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