librelist archives

« back to archive

Shortcomings in Attic

Shortcomings in Attic

From:
Dan Williams
Date:
2015-04-01 @ 09:46
Hi all

During my recent testing of Attic and comparison to other tools, I have kept
notes on missing features and things that don't work quite right.

I figured I'd mention them on the list before attempting to create any
tickets, in case I've missed something, and to get opinions.

Here's my list:


THINGS THAT DON'T WORK PROPERLY
===============================

1.  Sockets (and possibly other special files) are ignored

I found that if I have sockets in my backup data, they are not restored,
which I imagine means they are not backed up, either. This is rather
unexpected - I expect a backup tool to back *everything* up. It also makes
me wonder if there are other special files that are also ignored, e.g.
pipes.

Comparison note: Bup and Obnam correctly backed up and restored every type
of file I had.


2.  Sparse files are not sensibly handled

It would appear that sparse files are handled just like any other file. Not
only does this cause needless processing when backing up, it more critically
means that the full potential size is used upon restoration. This makes
Attic virtually unusable at this point in time for backing up virtual
machine disk images, which are often sparse.

Yes, it is possible to "re-sparsify" the file after extraction. However,
this is not without problems - there may not be enough disk space for the
expanded file and the sparse file to co-exist, plus it imposes an additional
time overhead.

This has already been commented on in the mailing list, so I am sure it will
be handled eventually...

Comparison note: Obnam correctly handles sparse files, but Bup doesn't.


MISSING FEATURES
================

1.  Specify the "extract to" location

This is somewhat puzzling, as I imagine it would be very easy to add. All
the other backup tools I tested allowed a path to be specified, to which the
extracted files would be restored. With Attic, it always restores to the
current working directory, which is a little annoying.

Comparison note: Bup, Obnam, and everything else I looked at allow this.


2.  Remove a path prefix on backup and/or restore

Attic uses the full path to back up. This is not always useful or wanted. In
many cases I might be backing up the contents of a user's home directory, or
files for a website or application, which may later be restored to a
different path. In those cases, the absolute path is not only irrelevant,
but annoying - it should be possible to extract at any point, from any
backup set, consistently, regardless of path changes that may have happened
in between (e.g. a website moving to a different server and having a
different base path).

I would not mind there being some kind of warning when backing up or
restoring a set which uses relative paths - perhaps, though, this would only
be needed if extracting the backup to the filesystem root (i.e. /).
Otherwise, it should be assumed that the user has read the manual and is
using the relative path options because they know how to.

Comparison note: Bup allows this sort of thing, e.g. most usefully through
its --graft option.


3.  Specify the date and time of the backup

This might seem a little odd, but is very useful when migrating backup sets
from other software. For instance, I recently converted a huge set of tgz
files to Bup, and specified the date and time for each, thereby recreating
the backup history. It doesn't have much use outside of this scenario, but
would allow migrated sets to play nicely with the `attic prune` command. I
imagine it's also a fairly simple addition.

Comparison note: Bup and Obnam both allow this.


4.  Progress indicator

Seems like such a little thing... currently, Attic whirrs away silently,
unless you tell it to be verbose, in which case it spews out loads of
filenames. I would prefer there to be a middle ground, as an option of
course (quiet by default is fine), which could at least give some details
about how much data it has processed, even if it were not possible to give
an overall percentage.

Comparison note: Obnam as a reasonably good progress indicator, but seeing
as Attic creates an index, it should be able to do better.


Cheers

Dan


Re: [attic] Shortcomings in Attic

From:
Thomas Waldmann
Date:
2015-04-01 @ 13:21
> 1.  Sockets (and possibly other special files) are ignored
>

https://github.com/jborg/attic/issues/259

It would help if other people could also test this and confirm (or not) -
please update the ticket accordingly.

 wonder if there are other special files that are also ignored, e.g. pipes.
>

Attic has some code for "special files", like directories, block/char
devices, fifos, symlinks, hardlinks, ...

>
> MISSING FEATURES
> ================
>

Could you check the issue tracker for these and, if needed, open a separate
new issue for each feature?


> 4.  Progress indicator
>

I implemented that already in my branch: --progress

It's NOT a progress bar, it is NOT giving "time remaining" and also not a
percentage or "x / y" - because I did not want to spend extra time by first
determining the total size / file count.

But at least one sees it is doing something and also the size / amount of
files already processed.
If you remember from last backup how much you have, you can do a rough
estimation based on it by yourself.

Re: [attic] Shortcomings in Attic

From:
Dan Williams
Date:
2015-04-01 @ 17:29
Note: The three issues are now on the Github issue list for "original" 
Attic as issues #261, #262, and #263.

 

https://github.com/jborg/attic/issues/261    Specify the "extract to" location

https://github.com/jborg/attic/issues/262    Remove a path prefix on 
backup and/or restore

https://github.com/jborg/attic/issues/263    Specify the date and time of 
the backup

 

 

 

From: Dan Williams [mailto:dan@dotfive.co.uk] 
Sent: 01 April 2015 14:51
To: 'attic@librelist.com'
Subject: RE: [attic] Shortcomings in Attic

 

Excellent – thanks for the pointers! And for creating #259. I am aware of 
the existing ticket for sparse files, so I’ll create some tickets for the 
three remaining features.

 

 

From: attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Thomas
Waldmann
Sent: 01 April 2015 14:22
To: attic@librelist.com
Subject: Re: [attic] Shortcomings in Attic

 

 

1.  Sockets (and possibly other special files) are ignored


https://github.com/jborg/attic/issues/259

It would help if other people could also test this and confirm (or not) - 
please update the ticket accordingly.

 wonder if there are other special files that are also ignored, e.g. pipes.

 

Attic has some code for "special files", like directories, block/char 
devices, fifos, symlinks, hardlinks, ...

 

MISSING FEATURES
================

 

Could you check the issue tracker for these and, if needed, open a 
separate new issue for each feature?
 

4.  Progress indicator

 

I implemented that already in my branch: --progress

It's NOT a progress bar, it is NOT giving "time remaining" and also not a 
percentage or "x / y" - because I did not want to spend extra time by 
first determining the total size / file count.


But at least one sees it is doing something and also the size / amount of 
files already processed.

If you remember from last backup how much you have, you can do a rough 
estimation based on it by yourself.

 

Sv: [attic] Shortcomings in Attic

From:
Petter Gunnerud
Date:
2015-04-02 @ 00:00
Regarding #262Could this be what you're looking for?
attic extract --strip-segments X
      Fra: Dan Williams <dan@dotfive.co.uk>
 Til: attic@librelist.com 
 Sendt: Onsdag, 1. april 2015 19.29
 Emne: RE: [attic] Shortcomings in Attic
   
<!--#yiv6802987330 _filtered #yiv6802987330 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered 
#yiv6802987330 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 
4;}#yiv6802987330 #yiv6802987330 p.yiv6802987330MsoNormal, #yiv6802987330 
li.yiv6802987330MsoNormal, #yiv6802987330 div.yiv6802987330MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv6802987330 a:link, #yiv6802987330 
span.yiv6802987330MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6802987330 a:visited, 
#yiv6802987330 span.yiv6802987330MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6802987330 
p.yiv6802987330MsoAcetate, #yiv6802987330 li.yiv6802987330MsoAcetate, 
#yiv6802987330 div.yiv6802987330MsoAcetate 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", 
"sans-serif";}#yiv6802987330 span.yiv6802987330EmailStyle17 
{font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv6802987330 
span.yiv6802987330EmailStyle18 {font-family:"Calibri", 
"sans-serif";color:#1F497D;}#yiv6802987330 
span.yiv6802987330BalloonTextChar {font-family:"Tahoma", 
"sans-serif";}#yiv6802987330 .yiv6802987330MsoChpDefault 
{font-size:10.0pt;} _filtered #yiv6802987330 {margin:72.0pt 72.0pt 72.0pt 
72.0pt;}#yiv6802987330 div.yiv6802987330WordSection1 {}-->Note: The three 
issues are now on the Github issue list for "original" Attic as issues 
#261, #262, and #263.  https://github.com/jborg/attic/issues/261    
Specify the "extract to" 
locationhttps://github.com/jborg/attic/issues/262    Remove a path prefix 
on backup and/or restore https://github.com/jborg/attic/issues/263    
Specify the date and time of the backup 

  

Re: [attic] Shortcomings in Attic

From:
Dan Williams
Date:
2015-04-02 @ 08:47
Do you mean `--strip-components X`?

 

It's not quite the same. Perhaps I should illustrate with an example:

 

Let's say you have a user, they live under `/home/joebloggs`. This user
needs all their files backed up into their own Attic repository (we won't
share files from different users in the same repository in this example,
because we want to give the users access). So, either they or the sysadmin
sets up a cron job or otherwise backs up their data.

 

Now, Attic will currently record the absolute path to the files backed up.
This means that the files we have in the repository are recorded and
accessed in this fashion. So far, that doesn't matter *too* much - we just
need to remember to do some moving around when extracting (or possibly to
carefully count the path segments and use `--strip-components`).

 

Then things change, and the sysadmin puts Mr. Bloggs into a jailed
environment. His home directory is now
`/home/jails/engineers/home/joebloggs`. From inside the jail, it looks like
the path is unchanged. But from outside the jail, it is clearly different.
Assume that the sysadmin has set up cron jobs for every user, and also
assume that users sometimes want to make their own backups at specific
times. See where I am going here? The paths won't match.

 

Similarly, if the username changes (maybe after a move to a different
server), or anything else resulting in a path change, we hit the same sort
of issue.

 

So, I think it is quite important to be able to specify *at creation time*
what the path we want is. If you are just backing up `/etc/` or other
root-filesystem stuff, you don't care, and would not change it. But
respecting the relative-path context is quite important for other (common)
uses, otherwise you cannot reliably use even `--strip-components` because
you have to remember which* backup sets had which path.

 

Bup offers three options to get around this: `--strip`, `--strip-path`, and
`--graft`. I find `--graft` the most useful, and arguably it supersedes the
other two options anyway. Reference: https://bup.github.io/man/bup-save.html

 

Oddly, Bup doesn't offer anything similar on restore. I think that ideally,
this functionality would be available on both sides (i.e. in `attic create`
and `attic extract`) because this gives the most flexibility. But it is the
creation-time stuff I am most interested in, and arguably
`--strip-components` may be enough for `extract` if a `--graft` equivalent
were introduced to `create`.

 

I hope that helps - just my opinion; others may differ! :o)

 

 

 

From: attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Petter
Gunnerud
Sent: 02 April 2015 01:00
To: attic@librelist.com
Subject: Sv: [attic] Shortcomings in Attic

 

Regarding #262

Could this be what you're looking for?

attic extract --strip-segments X

 

  _____  

Fra: Dan Williams <dan@dotfive.co.uk>
Til: attic@librelist.com 
Sendt: Onsdag, 1. april 2015 19.29
Emne: RE: [attic] Shortcomings in Attic

 

Note: The three issues are now on the Github issue list for "original" Attic
as issues #261, #262, and #263.

 

https://g ithub.com/jborg/attic/issues/261
<https://github.com/jborg/attic/issues/261>     Specify the "extract to"
location

https://github.com/jborg/attic/issues/262    Remove a path prefix on backup
and/or restore 

https://github.com/jborg/attic/issues/263    Specify the date and time of
the backup

 

 

Sv: [attic] Shortcomings in Attic

From:
Petter Gunnerud
Date:
2015-04-02 @ 10:40
From that example it looks to me that you're going from having to 
"remember which* backup sets had which path" (which you may find by 
looking at the backupsets content) towards "remember the users home path" 
(which you won't find in your repo at all). To me it seems you'd be better
of with a practice where you always add backupsets to a repo from within 
the same jail. Moving user to another jail would include moving the repo 
to the same jail, and make sure all access to the repo is performed from 
within that jail from the moment of moving.

Back in the days when I used jails, I found best practice to be an 
extensive use of mount --bind, and keep identical folder structure in the 
jails as outside. I used this for everything that should be accessible 
from within the jail, so that the real path /home/joe was also mounted as 
/jails/home/joe. Such practice would also solve your problem.
PG
 
     Fra: Dan Williams <dan@dotfive.co.uk>
 Til: attic@librelist.com 
 Sendt: Torsdag, 2. april 2015 10.47
 Emne: RE: [attic] Shortcomings in Attic
   
<!--#yiv9831943812 _filtered #yiv9831943812 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered 
#yiv9831943812 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} 
_filtered #yiv9831943812 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 
4;} _filtered #yiv9831943812 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4
2 4;}#yiv9831943812 #yiv9831943812 p.yiv9831943812MsoNormal, 
#yiv9831943812 li.yiv9831943812MsoNormal, #yiv9831943812 
div.yiv9831943812MsoNormal 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 a:link, #yiv9831943812 
span.yiv9831943812MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv9831943812 a:visited, 
#yiv9831943812 span.yiv9831943812MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv9831943812 
p.yiv9831943812MsoAcetate, #yiv9831943812 li.yiv9831943812MsoAcetate, 
#yiv9831943812 div.yiv9831943812MsoAcetate 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", 
"sans-serif";}#yiv9831943812 p.yiv9831943812msoacetate, #yiv9831943812 
li.yiv9831943812msoacetate, #yiv9831943812 div.yiv9831943812msoacetate 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 p.yiv9831943812msonormal, #yiv9831943812 
li.yiv9831943812msonormal, #yiv9831943812 div.yiv9831943812msonormal 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 p.yiv9831943812msochpdefault, 
#yiv9831943812 li.yiv9831943812msochpdefault, #yiv9831943812 
div.yiv9831943812msochpdefault 
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 span.yiv9831943812msohyperlink 
{}#yiv9831943812 span.yiv9831943812msohyperlinkfollowed {}#yiv9831943812 
span.yiv9831943812emailstyle17 {}#yiv9831943812 
span.yiv9831943812emailstyle18 {}#yiv9831943812 
span.yiv9831943812balloontextchar {}#yiv9831943812 
p.yiv9831943812msonormal1, #yiv9831943812 li.yiv9831943812msonormal1, 
#yiv9831943812 div.yiv9831943812msonormal1 
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 span.yiv9831943812msohyperlink1 
{color:blue;text-decoration:underline;}#yiv9831943812 
span.yiv9831943812msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv9831943812 
p.yiv9831943812msoacetate1, #yiv9831943812 li.yiv9831943812msoacetate1, 
#yiv9831943812 div.yiv9831943812msoacetate1 
{margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", 
"sans-serif";}#yiv9831943812 span.yiv9831943812emailstyle171 
{font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv9831943812 
span.yiv9831943812emailstyle181 {font-family:"Calibri", 
"sans-serif";color:#1F497D;}#yiv9831943812 
span.yiv9831943812balloontextchar1 {font-family:"Tahoma", 
"sans-serif";}#yiv9831943812 p.yiv9831943812msochpdefault1, #yiv9831943812
li.yiv9831943812msochpdefault1, #yiv9831943812 
div.yiv9831943812msochpdefault1 
{margin-right:0cm;margin-left:0cm;font-size:10.0pt;font-family:"Times New 
Roman", "serif";}#yiv9831943812 span.yiv9831943812EmailStyle33 
{font-family:"Calibri", "sans-serif";color:#1F497D;}#yiv9831943812 
span.yiv9831943812BalloonTextChar {font-family:"Tahoma", 
"sans-serif";}#yiv9831943812 .yiv9831943812MsoChpDefault 
{font-size:10.0pt;} _filtered #yiv9831943812 {margin:72.0pt 72.0pt 72.0pt 
72.0pt;}#yiv9831943812 div.yiv9831943812WordSection1 {}-->Do you mean 
`--strip-components X`?  It’s not quite the same… Perhaps I should 
illustrate with an example:  Let’s say you have a user, they live under 
`/home/joebloggs`. This user needs all their files backed up into their 
own Attic repository (we won’t share files from differe nt users in the 
same repository in this example, because we want to give the users 
access). So, either they or the sysadmin sets up a cron job or otherwise 
backs up their data.  Now, Attic will currently record the absolute path 
to the files backed up. This means that the files we have in the 
repository are recorded and accessed in this fashion. So far, that doesn’t
matter *too* much – we just need to remember to do some moving around when
extracting (or possibly to carefully count the path segments and use 
`--strip-components`).  Then things change, and the sysadmin puts Mr. 
Bloggs into a jailed environment. His home directory is now 
`/home/jails/engineers/home/joebloggs`. From inside the jail, it looks 
like the path is unchanged. But from outside the jail, it is clearly 
different. Assume that the sysadmin has set up cron jobs for every user, 
and also assume that users sometimes want to make their own backups at 
specific times. See where I am going here? The paths won’t match. 
 Similarly, if the username changes (maybe after a move to a different 
server), or anything else resulting in a path change, we hit the same sort
of issue.  So, I think it is quite important to be able to specify *at 
creation time* what the path we want is. If you are just backing up 
`/etc/` or other root-filesystem stuff, you don’t care, and would not 
change it. But respecting the relative-path context is quite important for
other (common) uses, otherwise you cannot reliably use even 
`--strip-components` because you have to remember which* backup sets had 
which path.  Bup offers three options to get around this: `--strip`, 
`--strip-path`, and `--graft`. I find `--graft` the most useful, and 
arguably it supersedes the other two option s anyway. Reference: 
https://bup.github.io/man/bup-save.html  Oddly, Bup doesn’t offer anything
similar on restore. I think that ideally, this functionality would be 
available on both sides (i.e. in `attic create` and `attic extract`) 
because this gives the most flexibility. But it is the creation-time stuff
I am most interested in, and arguably `--strip-components` may be enough 
for `extract` if a `--graft` equivalent were introduced to `create`.  I 
hope that helps – just my opinion; others may differ! :o)      From: 
attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Petter 
Gunnerud
Sent: 02 April 2015 01:00
To: attic@librelist.com
Su bject: Sv: [attic] Shortcomings in Attic  Regarding #262Could this be 
what you're looking for?attic extract --strip-segments X  Fra: Dan 
Williams <dan@dotfive.co.uk>
Til: attic@librelist.com 
Sendt: Onsdag, 1. april 2015 19.29
Emne: RE: [attic] Shortcomings in Attic  Note: The three issues are now on
the Github issue list for "original" Attic as issues #261, #262, and 
#263. https://g ithub.com/jborg/attic/issues/261    Specif y the "extract 
to" locationhttps://github.com/jborg/attic/issues/262    Remove a path 
prefix on backup and/or restore 
https://github.com/jborg/attic/issues/263    Specify the date and time of 
the backup</ span>   

  

Re: [attic] Shortcomings in Attic

From:
Dan Williams
Date:
2015-04-02 @ 11:06
The jail was but one of the examples… a different real-world example is 
that on most of the web applications I back up, I wish to only backup the 
stuff in the backup folder. The path to the backup folder is not 
important, and could in fact be anywhere, as it theoretically is in a 
temporary location. (The web applications produce their own backup files, 
i.e. dump of current data and state, and this is what I then back up – I 
do not back up the application’s entire filesystem as that would include 
installed files etc. and not include the database dump.) Hence in the 
backup repository the ideal is that all paths should be relative to the 
folder the backup was performed from.

 

I understand your position and in many cases you are correct. However I do
not feel it is the optimum strategy in *all* cases, or for all users. For 
instance in your example I would not have any username-resolution problem 
because that is an intrinsic property of where I would be storing the 
backup repository.

 

I do however agree that doing something like a chroot, mount --bind, or 
something along those lines *may* solve a number of situations like this. 
Yet it seems an unnecessary and awkward step to have to do everywhere, and
in less-suitable cases adds a layer of complexity that I’d rather do 
without. It should be easy to achieve, if required (if not required, you’d
just not use it).

 

I’d not want to impose my requirement or system of working upon you – 
ideally the tool should be flexible enough to support both of our 
approaches :o)

 

Hence I still think this is a very useful feature, and likely not 
particularly difficult to implement (although that is a guess!). The 
presence of such features in other backup programs shows that other people
have encountered the same scenario, so I am not alone…

 

 

 

From: attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Petter
Gunnerud
Sent: 02 April 2015 11:40
To: attic@librelist.com
Subject: Sv: [attic] Shortcomings in Attic

 

From that example it looks to me that you're going from having to 
"remember which* backup sets had which path" (which you may find by 
looking at the backupsets content) towards "remember the users home path" 
(which you won't find in your repo at all). To me it seems you'd be better
of with a practice where you always add backupsets to a repo from within 
the same jail. Moving user to another jail would include moving the repo 
to the same jail, and make sure all access to the repo is performed from 
within that jail from the moment of moving.

Back in the days when I used jails, I found best practice to be an 
extensive use of mount --bind, and keep identical folder structure in the 
jails as outside. I used this for everything that should be accessible 
from within the jail, so that the real path /home/joe was also mounted as 
/jails/home/joe. Such practice would also solve your problem.

 

PG

 

  _____  

Fra: Dan Williams <dan@dotfive.co.uk>
Til: attic@librelist.com 
Sendt: Torsdag, 2. april 2015 10.47
Emne: RE: [attic] Shortcomings in Attic

 

Do you mean `--strip-components X`?

 

It’s not quite the same… Perhaps I should illustrate with an example:

 

Let’s say you have a user, they live under `/home/joebloggs`. This user 
needs all their files backed up into their own Attic repository (we won’t 
share files from differe nt users in the same repository in this example, 
because we want to give the users access). So, either they or the sysadmin
sets up a cron job or otherwise backs up their data.

 

Now, Attic will currently record the absolute path to the files backed up.
This means that the files we have in the repository are recorded and 
accessed in this fashion. So far, that doesn’t matter *too* much – we just
need to remember to do some moving around when extracting (or possibly to 
carefully count the path segments and use `--strip-components`).

 

Then things change, and the sysadmin puts Mr. Bloggs into a jailed 
environment. His home directory is now 
`/home/jails/engineers/home/joebloggs`. From inside the jail, it looks 
like the path is unchanged. But from outside the jail, it is clearly 
different. Assume that the sysadmin has set up cron jobs for every user, 
and also assume that users sometimes want to make their own backups at 
specific times. See where I am going here? The paths won’t match.

 

Similarly, if the username changes (maybe after a move to a different 
server), or anything else resulting in a path change, we hit the same sort
of issue.

 

So, I think it is quite important to be able to specify *at creation time*
what the path we want is. If you are just backing up `/etc/` or other 
root-filesystem stuff, you don’t care, and would not change it. But res 
pecting the relative-path context is quite important for other (common) 
uses, otherwise you cannot reliably use even `--strip-components` because 
you have to remember which* backup sets had which path.

 

Bup offers three options to get around this: `--strip`, `--strip-path`, 
and `--graft`. I find `--graft` the most useful, and arguably it 
supersedes the other two option s anyway. Reference: 
https://bup.github.io/man/bup-save.html

 

Oddly, Bup doesn’t offer anything similar on restore. I think that 
ideally, this functionality would be available on both sides (i.e. in 
`attic create` and `attic extract`) because this gives the most 
flexibility. But it is the creation-time stuff I am most interested in, 
and arguably `--strip-components` may be enough for `extract` if a 
`--graft` equivalent were introduced to `create`.

 

I hope that helps – just my opinion; others may differ! :o)

 

 

 

From: attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Petter
Gunnerud
Sent: 02 April 2015 01:00
To: attic@librelist.com
Su bject: Sv: [attic] Shortcomings in Attic

 

Regarding #262

Could this be what you're looking for?

attic extract --strip-segments X

 

  _____  

Fra: Dan Williams <dan@dotfive.co.uk>
Til: attic@librelist. com <mailto:attic@librelist.com>  
Sendt: Onsdag, 1. april 2015 19.29
Emne: RE: [attic] Shortcomings in Attic

 

Note: The three issues are now on the Github issue list for "original" 
Attic as issues #261, #262, and #263.

 

https://g ithub.com/jborg/attic/issues/261 
<https://github.com/jborg/attic/issues/261>     Specif y the "extract to" 
location

https://github.com/jborg/attic/issues/262    Remove a path prefix on 
backup and/or restore 

https://github.com/jborg/attic/iss ues/263 
<https://github.com/jborg/attic/issues/263>     Specify the date and time 
of the backup</ span>

 

 

 

Re: [attic] Shortcomings in Attic

From:
Dan Williams
Date:
2015-04-01 @ 13:51
Excellent – thanks for the pointers! And for creating #259. I am aware of 
the existing ticket for sparse files, so I’ll create some tickets for the 
three remaining features.

 

 

From: attic@librelist.com [mailto:attic@librelist.com] On Behalf Of Thomas
Waldmann
Sent: 01 April 2015 14:22
To: attic@librelist.com
Subject: Re: [attic] Shortcomings in Attic

 

 

1.  Sockets (and possibly other special files) are ignored


https://github.com/jborg/attic/issues/259

It would help if other people could also test this and confirm (or not) - 
please update the ticket accordingly.

 wonder if there are other special files that are also ignored, e.g. pipes.

 

Attic has some code for "special files", like directories, block/char 
devices, fifos, symlinks, hardlinks, ...

 

MISSING FEATURES
================

 

Could you check the issue tracker for these and, if needed, open a 
separate new issue for each feature?
 

4.  Progress indicator

 

I implemented that already in my branch: --progress

It's NOT a progress bar, it is NOT giving "time remaining" and also not a 
percentage or "x / y" - because I did not want to spend extra time by 
first determining the total size / file count.


But at least one sees it is doing something and also the size / amount of 
files already processed.

If you remember from last backup how much you have, you can do a rough 
estimation based on it by yourself.