Re: [BackupPC-users] Feature request

[Adam Goryachev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/08/11 11:40, Holger Parplies wrote:
> For what I think you have in mind I would always use a BackupPC_tarCreate
> invocation.
> 
> Of course, your preferences may vary. There might be situations where
> downloading an "archive" type tar file via HTTP is both practical and the
> most simple solution. In this case, you won't want a name like "restore.tar",
> but you might just as well have different preferences/requirements than
> whatever BackupPC is going to suggest. In my experience, deleting or
> rearranging parts of overly long filename suggestions can be just as
> annoying as having to fill out "obvious" information. The best solution
> would be to have the suggestion customizable (as in "%h-%n-%s"), but that's
> probably a lot of work for little effect (and it should strictly be a per-host
> setting). As a simpler solution, I'd suggest "restore-%h-%n" (where %h is the
> host name and %n the backup number) (and the .tar/.zip suffix, of course). If
> the date of the backup is easily available to the code in question, I'd prefer
> the date over the backup number, though there are bound to be people who have
> more than one backup on the same date (happens to me if one backup is delayed
> past midnight and the next one isn't). Maybe date + backup number. Remember
> that even though you might only have 9 backups the backup numbers aren't
> intended to wrap around, so they would still be unique for one host unless
> you start over with a fresh pool.

Just a small note, I've kept quiet so far, but anyway.. I agree with
most of what you say, and personally, I'd suggest the simplest change
which gets the greatest benefit it the best solution here. ie, don't try
to make everyone happy, just most of people :).

Thus, a filename of bpc_restore_$host_$number_$share.(tar|zip)

IMHO, if you selected one or more files from a single share (most cases
I suspect), then you show that specific share name.
If you select one or more files from multiple shares then use the share
name of "multiple" or exclude the share name.

Personally, I don't want the date/time of when the backup was started,
completed, nor the date/time of the files/etc... all that is just a
nuisance and asking for trouble with different date formats, timezones,
etc...

The backup number will provide enough info to go and lookup the
date/time if you really need it, and/or give you a rough idea of how old
the file is even if you have purged that old backup (ie, 100 backups ago
is about 100 days if you do backups daily).

If any date/time is really desirable, how about the date/time the
restore was done (purely to keep multiple restores of the same host/etc
sorted. The restore you did two hours ago compared to the restore you
did 30 minutes ago... Again, though, I don't see this as all that
sensible because you can always check the mtime or ctime of the file
itself...

Just my 0.02c...

Regards,
Adam

- -- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5W/tQACgkQGyoxogrTyiXRWACgjNX6dDp7+i2qmHYHfSNvVPVl
jAkAniDzwxt2IuwzqbHisLyLZIYLqsB5
=nCZg
-END PGP SIGNATURE-

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Holger Parplies]

Hi,

first of all, it seems to be *possible* to implement [without major code
changes], in case anyone except me was wondering ;-).

Carl Wilhelm Soderstrom wrote on 2011-08-25 13:40:47 -0500 [Re: 
[BackupPC-users] Feature request]:
> On 08/25 02:22 , Brad Alexander wrote:
> > You could substitute "Full" for a root-level restore... So it could be
> 
> sounds reasonable.
> I might suggest 'root' instead of 'full' or '/'; because a restore starting

(I'm always confused by your usage of ";" ...)

> at / is not necessarily a restore of everything. [...]
> 
> The suggestion of not using a sharename for restores starting from the root;
> perhaps could be restated as something like " '/' characters shall be
> converted to '_' characters except for the leftmost one, which shall be
> omitted". this would end up omitting the sharename (or path or whatever it
> ends up being) if it's just '/'.
> 
> [...]
> 
> This may be a case where empirical testing serves better than theoretical
> wrangling. Let's see if long filenames actually occur and cause problems;
> and how drastic the solutions to them need to be.

well, let's consider where we are. We're in the CGI interface, where someone
marks a list of files or directories and selects to download them. So we not
only *definitely* have arbitrarily long paths (depending on where within the
backup the file(s) is/are that are requested), we have an arbitrary amount of
them. This can *easily* exceed maximum path lengths and test browsers for
buffer overflow vulnerabilities ;-).

Moreover, what is being suggested is merely a *convenience* for the person
downloading the tar/zip. Let's not turn it into an *inconvenience* for him.

Personally, I use the download function for retrieving files from backups
that I need immediately (rather than restoring them in-place which seems
rather error-prone). "restore.tar" is just fine for me, it's the tar of the
files I just retrieved. I untar it and remove the tar file. In the unlikely
event that I should need it again, I can always re-download it (well,
presuming the backup hasn't expired, but I'm thinking about a time frame of
minutes, here). Actually, I might even make a point of *excluding* files named
restore.tar or restore.zip from my backups, though for that, names like
BPC_restore.{tar,zip} might be better.

For what I think you have in mind I would always use a BackupPC_tarCreate
invocation.

Of course, your preferences may vary. There might be situations where
downloading an "archive" type tar file via HTTP is both practical and the
most simple solution. In this case, you won't want a name like "restore.tar",
but you might just as well have different preferences/requirements than
whatever BackupPC is going to suggest. In my experience, deleting or
rearranging parts of overly long filename suggestions can be just as
annoying as having to fill out "obvious" information. The best solution
would be to have the suggestion customizable (as in "%h-%n-%s"), but that's
probably a lot of work for little effect (and it should strictly be a per-host
setting). As a simpler solution, I'd suggest "restore-%h-%n" (where %h is the
host name and %n the backup number) (and the .tar/.zip suffix, of course). If
the date of the backup is easily available to the code in question, I'd prefer
the date over the backup number, though there are bound to be people who have
more than one backup on the same date (happens to me if one backup is delayed
past midnight and the next one isn't). Maybe date + backup number. Remember
that even though you might only have 9 backups the backup numbers aren't
intended to wrap around, so they would still be unique for one host unless
you start over with a fresh pool.

Regards,
Holger

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Backuppc problem with filenames

[Jesper Haggren - NHL Data]

Hi Paul,

For your information I also have a server running latest version 3.2.1 
built from source  and it also works just fine.


/Jesper



On 25-08-2011 20:56, Paul Cain wrote:

Hi Jesper,
Thanks again for your response and your test results.
This certainly has me baffled.
I guess I'll try and re-install backuppc w/version 3.1 and see if that helps.
Regards,
Paul
  
  


Hi Paul,

Just tested it on one of my BackupPC servers.
Now mine is installed on Debian6 x64, and uses the stable backuppc
package (3.1.0) from the Debian repositories.

Result here:
http://public.haggren.com/for_paul/test.png

/Jesper



On 24-08-2011 21:07, Paul Cain wrote:
>  Hello,
>  This is a follow up post to the original issue.
>  I have done some additonal testing and now it seems that the issue is
>  specifically related to either backuppc or the File::RsyncP module, as
>  these are the two pieces I can not eliminate.
>  I have setup and successfully completed straight rsync file transfer
>  from the winXP box to the Unbuntu (10.04) with no issue.  All files
>  transferred with out any changes to the filename. I have scoured the
>  various user forums for any related problems and aside from a few
>  people who had issues relating to European character sets not
>  translating properly (which I have eliminated as a possible solution)
>  there are no issue being reported.  It seem sthat I am the only one to
>  create filenames starting with an open parenthesis
>  Is anyone able to test this issue on their system and see if it is
>  indeed common?
>  Regards,
>  Paul


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Backuppc problem with filenames

[Paul Cain]

Hi Jesper,
Thanks again for your response and your test results. 
This certainly has me baffled. 
I guess I'll try and re-install backuppc w/version 3.1 and see if that
helps.
Regards,
Paul
 
 

Hi Paul,



Just tested it on one of my BackupPC servers.

Now mine is installed on Debian6 x64, and uses the stable backuppc 

package (3.1.0) from the Debian repositories.



Result here:

 
http://public.haggren.com/for_paul/test.png



/Jesper







On 24-08-2011 21:07, Paul Cain wrote:

> Hello,

> This is a follow up post to the original issue.

> I have done some additonal testing and now it seems that the issue is 

> specifically related to either backuppc or the File::RsyncP module, as 

> these are the two pieces I can not eliminate.

> I have setup and successfully completed straight rsync file transfer 

> from the winXP box to the Unbuntu (10.04) with no issue.  All files 

> transferred with out any changes to the filename. I have scoured the 

> various user forums for any related problems and aside from a few 

> people who had issues relating to European character sets not 

> translating properly (which I have eliminated as a possible solution) 

> there are no issue being reported.  It seem sthat I am the only one to 

> create filenames starting with an open parenthesis

> Is anyone able to test this issue on their system and see if it is 

> indeed common?

> Regards,

> Paul

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Carl Wilhelm Soderstrom]

On 08/25 02:22 , Brad Alexander wrote:
> You could substitute "Full" for a root-level restore... So it could be

sounds reasonable.
I might suggest 'root' instead of 'full' or '/'; because a restore starting
at / is not necessarily a restore of everything. However, 'root' has its own
problems in that the word also describes a user on almost every *nix
machine.


The suggestion of not using a sharename for restores starting from the root;
perhaps could be restated as something like " '/' characters shall be
converted to '_' characters except for the leftmost one, which shall be
omitted". this would end up omitting the sharename (or path or whatever it
ends up being) if it's just '/'.

> hostname_20110824_Full.tar or hostname_20110824_etc_home.zip (assuming the
> restore is /etc and /home)...The only problem with that is the name can get
> long and tedious. Suggestions on that?


This may be a case where empirical testing serves better than theoretical
wrangling. Let's see if long filenames actually occur and cause problems;
and how drastic the solutions to them need to be.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Bowie Bailey]

On 8/25/2011 2:22 PM, Brad Alexander wrote:
>
> You could substitute "Full" for a root-level restore... So it could be
>
> hostname_20110824_Full.tar or hostname_20110824_etc_home.zip (assuming
> the restore is /etc and /home)...The only problem with that is the
> name can get long and tedious. Suggestions on that?

I don't think the filename needs to be overly specific.  I would suggest
using hostname, date, and either "Full" or "Partial".  Anyone that needs
to get more specific can rename the file later.

-- 
Bowie

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Brad Alexander]

On Thu, Aug 25, 2011 at 9:31 AM, Carl Wilhelm Soderstrom <
chr...@real-time.com> wrote:

> On 08/25 09:23 , Jeffrey J. Kosowsky wrote:
> > I would make it consistent with the heirarchy:
> > --
> > I'm not sure what date adds since the date is irrelevant unless you
> > are referring to the date of the snapshot in which case it would be an
> > alternative to backup#.
>
> I would prefer date, since the 'backup number' is only relevant within
> BackupPC's universe; whereas the date is relevant to the rest of the world.
>

Concur, plus backup numbers have a shelf life, I have roughly 9 backups.


> > Also, "share" should be optional in case the restore is done at the
> > host level.
>
> Even when restoring an entire host, the share must be specified, correct?
> One problem is that '/' is a character with special meaning on the command
> line; and so we should avoid putting it in filenames. Suggestions?
>

You could substitute "Full" for a root-level restore... So it could be

hostname_20110824_Full.tar or hostname_20110824_etc_home.zip (assuming the
restore is /etc and /home)...The only problem with that is the name can get
long and tedious. Suggestions on that?

--b
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Carl Wilhelm Soderstrom]

On 08/25 10:45 , Jeffrey J. Kosowsky wrote:
> Carl Wilhelm Soderstrom wrote at about 08:31:01 -0500 on Thursday, August 25, 
> 2011:
>  > On 08/25 09:23 , Jeffrey J. Kosowsky wrote:
>  > > I would make it consistent with the heirarchy:
>  > > --
>  > > I'm not sure what date adds since the date is irrelevant unless you
>  > > are referring to the date of the snapshot in which case it would be an
>  > > alternative to backup#.
>  > 
>  > I would prefer date, since the 'backup number' is only relevant within
>  > BackupPC's universe; whereas the date is relevant to the rest of the world.
> 
> My point was more that the date should refer to the time of the backup
> not of the restore.

Certainly!

> I think one should use the encoding used for the share name in the pc
> tree. There are characters other than '/' that could cause problems
> such as special or foreign characters on one client that might not be
> allowed or present on the server.

ok.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Jeffrey J. Kosowsky]

Carl Wilhelm Soderstrom wrote at about 08:31:01 -0500 on Thursday, August 25, 
2011:
 > On 08/25 09:23 , Jeffrey J. Kosowsky wrote:
 > > I would make it consistent with the heirarchy:
 > > --
 > > I'm not sure what date adds since the date is irrelevant unless you
 > > are referring to the date of the snapshot in which case it would be an
 > > alternative to backup#.
 > 
 > I would prefer date, since the 'backup number' is only relevant within
 > BackupPC's universe; whereas the date is relevant to the rest of the world.

My point was more that the date should refer to the time of the backup
not of the restore.

 > 
 > > Also, "share" should be optional in case the restore is done at the
 > > host level.
 > 
 > Even when restoring an entire host, the share must be specified, correct?
 > One problem is that '/' is a character with special meaning on the command
 > line; and so we should avoid putting it in filenames. Suggestions?

I think one should use the encoding used for the share name in the pc
tree. There are characters other than '/' that could cause problems
such as special or foreign characters on one client that might not be
allowed or present on the server.

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Carl Wilhelm Soderstrom]

On 08/25 09:23 , Jeffrey J. Kosowsky wrote:
> I would make it consistent with the heirarchy:
> --
> I'm not sure what date adds since the date is irrelevant unless you
> are referring to the date of the snapshot in which case it would be an
> alternative to backup#.

I would prefer date, since the 'backup number' is only relevant within
BackupPC's universe; whereas the date is relevant to the rest of the world.


> Also, "share" should be optional in case the restore is done at the
> host level.

Even when restoring an entire host, the share must be specified, correct?
One problem is that '/' is a character with special meaning on the command
line; and so we should avoid putting it in filenames. Suggestions?


-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Jeffrey J. Kosowsky]

Carl Wilhelm Soderstrom wrote at about 07:51:10 -0500 on Thursday, August 25, 
2011:
 > On 08/25 07:50 , Brad Alexander wrote:
 > > Really a small thing, but when doing a restore, and you save as a .zip or
 > > .tar, instead of defaulting to a generic and non-descriptive filename of
 > > restore.{tar|zip}, how about something more descriptive, such as
 > > --.{tar|zip}?
 > 
 > I second this request!
 > I believe filenames should always be as descriptive as is reasonable.
 > Unfortunately my perl-fu is pretty weak as well.

I would make it consistent with the heirarchy:
--
I'm not sure what date adds since the date is irrelevant unless you
are referring to the date of the snapshot in which case it would be an
alternative to backup#.
Also, "share" should be optional in case the restore is done at the
host level.

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] Feature request

[Carl Wilhelm Soderstrom]

On 08/25 07:50 , Brad Alexander wrote:
> Really a small thing, but when doing a restore, and you save as a .zip or
> .tar, instead of defaulting to a generic and non-descriptive filename of
> restore.{tar|zip}, how about something more descriptive, such as
> --.{tar|zip}?

I second this request!
I believe filenames should always be as descriptive as is reasonable.
Unfortunately my perl-fu is pretty weak as well.


-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

[BackupPC-users] Feature request

[Brad Alexander]

Really a small thing, but when doing a restore, and you save as a .zip or
.tar, instead of defaulting to a generic and non-descriptive filename of
restore.{tar|zip}, how about something more descriptive, such as
--.{tar|zip}?

I was going to have a look at the code and see if I could whip up a patch,
with my weak perl-foo, but I thought I would make the suggestion now.

Thanks,
--b
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/