From: Brad A. <st...@gm...> - 2011-08-25 11:50:37
|
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 <hostname>-<filesystem>-<date>.{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 |
From: Carl W. S. <ch...@re...> - 2011-08-25 12:51:17
|
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 > <hostname>-<filesystem>-<date>.{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 |
From: Jeffrey J. K. <bac...@ko...> - 2011-08-25 13:23:53
|
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 > > <hostname>-<filesystem>-<date>.{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: <hostname>-<backup#>-<share> 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. |
From: Carl W. S. <ch...@re...> - 2011-08-25 13:31:07
|
On 08/25 09:23 , Jeffrey J. Kosowsky wrote: > I would make it consistent with the heirarchy: > <hostname>-<backup#>-<share> > 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 |
From: Brad A. <st...@gm...> - 2011-08-25 18:22:25
|
On Thu, Aug 25, 2011 at 9:31 AM, Carl Wilhelm Soderstrom < ch...@re...> wrote: > On 08/25 09:23 , Jeffrey J. Kosowsky wrote: > > I would make it consistent with the heirarchy: > > <hostname>-<backup#>-<share> > > 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 |
From: Bowie B. <Bowie_Bailey@BUC.com> - 2011-08-25 18:38:51
|
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 |
From: Jeffrey J. K. <bac...@ko...> - 2011-08-25 14:45:59
|
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: > > <hostname>-<backup#>-<share> > > 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. |
From: Carl W. S. <ch...@re...> - 2011-08-25 16:24:12
|
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: > > > <hostname>-<backup#>-<share> > > > 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 |
From: Carl W. S. <ch...@re...> - 2011-08-25 18:40:54
|
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 |
From: Brad A. <st...@gm...> - 2011-08-26 11:00:35
|
On Thu, Aug 25, 2011 at 2:40 PM, Carl Wilhelm Soderstrom < ch...@re...> wrote: > > 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. > Good point. I was thinking about a box I rebuilt this week. Before I rebuilt it, I saved /root, /home and /etc. So my potential filename would have been akagi_20110823_etc_home_root.tar, which would be manageable, but you could see how it could get out of hand rather quickly...especially if you are preserving, say, /usr/local/bin versus /usr/bin... --b |
From: Holger P. <wb...@pa...> - 2011-08-26 01:41:26
|
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 |
From: Adam G. <mai...@we...> - 2011-08-26 02:03:16
|
-----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----- |
From: Carl W. S. <ch...@re...> - 2011-08-29 15:02:46
|
On 08/26 03:40 , Holger Parplies wrote: > Carl Wilhelm Soderstrom wrote on 2011-08-25 13:40:47 -0500 [Re: [BackupPC-users] Feature request]: > > I might suggest 'root' instead of 'full' or '/'; because a restore starting > > (I'm always confused by your usage of ";" ...) Heh. Sometimes I overemphasize the pauses & junctures in my train of thought. I realize it's mediocre grammar when I go back and re-read it, but I don't usually proofread and edit my mails heavily. ;) > 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 ;-). This is a good point. > 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. True. I agree that it should be a sensible default for most people. This isn't something that *needs* a lot of customization capability (especially considering how long we've gone before anyone was inconvenienced enough to write an e-mail about it). > 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. This is indeed a sensible default. I have had situations where I needed to retrieve several files tho (possibly from different machines), and I sometimes forget to delete a file after using it, and so I rename files to something that describes what is in them so I can avoid confusion with a glance. > In my experience, deleting or > rearranging parts of overly long filename suggestions can be just as > annoying as having to fill out "obvious" information. Agreed. > 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. On 08/26 12:03 , Adam Goryachev wrote: > 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. I agree that backup numbers are nicely shorter than date numbers (even '20110829' is longer than '1036'); but OTOH I don't have a miserable clue what that backup sequence number means, whereas I do know what a date is, and that's what the end-user cares about anyway. So rather than have me do the translation between backup number and date in my head (and get it wrong), I believe it would be far superior to include the date in the filename. As a simple improvement and compromise, I would support something like "bpc_restore-<date>-<host>.<ext>". For example "bpc_restore-20110829-www.foobar.com.tar". I do however realize that this is unpleasantly long already for some applications. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com |
From: Richard S. <hob...@gm...> - 2011-08-29 15:15:28
|
Ok, jumping in here a bit late :) Would it be easy to add a field in the GUI for this? Something like: Archive Name "$host-$backup-date..." I'm making up the variable names but use the ones already available and set the default to the current default. That way people could use whatever combination of perl (and perhaps shell?) variables they have available or wish to define? Richard |