Hi,
Sorin Srbu wrote on 2011-04-14 08:33:10 +0200 [Re: [BackupPC-users] How to
restore an 8GB archive file?]:
> >-----Original Message-----
> >From: Jeffrey J. Kosowsky [mailto:********@********.org]
please don't do that. At least now I know why I'm getting spam to my
backuppc-list-only email address.
> >To: General list for user discussion, questions and support
Much better, though this address is probably less sensitive ...
> >Cc: sorin.srbu AT orgfarm.uu DOT se
Your problem :-).
> [...]
> Moving the 8GB archive to a machine with ext4, solved the problem.
I agree with the other opinions. Amongst other things, you changed the file
system. I doubt this was the relevant change.
> OTOH, ext3 is said to have a max file size limit from about 16GB up to
> some 2TB, depending on block size.
Several years ago, I worried about file sizes, too. It turned out to "just
work" even back then. I haven't encountered such limits in years. Then again,
on relevant file systems I don't tend to use ext3, because it *still* seems to
have occasional problems with online resizing (admittedly on a Debian etch
installation; might have gone away since). Huge files seem to go hand in hand
with online resizing requirements.
Sorin Srbu wrote on 2011-04-14 08:37:54 +0200 [Re: [BackupPC-users] How to
restore an 8GB archive file?]:
> [...]
> >From: Les Mikesell
> >Sent: Wednesday, April 13, 2011 5:10 PM
> >>> Why don't you just restore it back to his machine, using the typical
> >>> option 1? If BackupPC archived it in the first place, it can restore it
> >>> the same way.
> >>
> >> I've never had that option to work. This time I got a weird "unable to
> >read 4 bytes"-error when trying a direct restore.
> >
> >Usually that means the restore is configured to use ssh in some way, and
> >the ssh keys aren't set up correctly. Is there something different
> >about the way your restore command works?
>
> I do use passwordless login for the backups to work. The backup works fine
> using ssh this way; I don't get prompted for a password.
>
> Not sure though, how you mean different for restoring. Could you elaborate a
> bit?
You've got it the wrong way around. *You* need to elaborate. What are your
RsyncClientCmd and RsyncClientRestoreCmd (it was rsync, wasn't it?)? If we
knew those, we could see what might be misconfigured or causing problems (or
what is even *involved* in backing up/restoring in your setup).
> I haven't really looked into the first restore option, ie tweaked in any
> way, as #2 and #3 have worked fine so far, until now.
Well, then it may be set incorrectly. Or not. Depending on what you did to the
backup command.
Sorin Srbu wrote on 2011-04-14 08:47:12 +0200 [Re: [BackupPC-users] How to
restore an 8GB archive file?]:
> >From: Holger Parplies
> >Sent: Thursday, April 14, 2011 12:38 AM
> >
> >- Which user on the target host do you need to connect as? Perhaps root?
>
> When the "backuppc" user connects to a host to do a backup, it uses a
> passwordless login with ssh keys. The password entered the very first time I
> transferred the key, was root's. So does this mean it's user "backuppc" that
> does the actual restore or user "root"?
Well, you took away the context, so it's not obvious you misunderstood the
question (which wasn't one, actually).
If you use computers to do things, you need to think. There is no way around
that. Even a nice shiny GUI does not have a "do the right thing, now" button.
Downloading a tar file over the GUI requires you to think about where to do
that and how to get the tar file to the destination computer, as the right
user, and where to put it. There might be a simple solution (go to the
destination computer and download the tar file from a browser belonging to
the user, and he'll tell you where to put it), but there might as well be
many obstacles (not enough tmp space, broken browser version, no network
access to the BackupPC server, slow network link, transparent proxy, user
out for lunch, user needs to leave before the download is complete ...).
Some of these might even impose *arbitrary* file size limits when downloading
(browsers seem to have *strange* solutions for starting downloads before they
know where to put the file).
You might "automatically" select the right option, or you might not think
about it at all and just get away with it. Or hit something that looks like a
file system problem, but can't really be explained.
Concerning the selection of an ssh target user, if you want a generic answer,
use root, that will always work (but has the potential to do more harm if you
get something wrong). For your case, if you *can* log in as the file owner
(all files in the restore belong to him, right?), then do that. Maybe I should
have written "select the target user that makes most sense in each respective
case".
All of this has *nothing* to do with BackupPC doing backups. It's only about
*you* getting the user's files back on his computer. And it's coincidentally
similar to how automatic restores would work, except that they need a generic
(and non-interactive) solution, whereas you can use anything that works for
you.
Setting up automatic restores is an independent matter. I make a habit of
expressly disallowing automatic restores, because it's too easy to overwrite
valid, new data (that has not been backed up yet) with old versions by
clicking on the wrong buttons in the GUI. Restores are a potentially
destructive operation and require thought and concentration. But that's just
my opinion. If you like the GUI, feel free to set up automatic restores.
> If the first, then I can understand that the user backuppc can't write to
> anywhere, right?
For backups, BackupPC also needs to *read* files that any random user may not
have access to, so there is generally a method of getting root permission
involved ('ssh -l root' or 'sudo'), unless your backups are supposed to
contain only files readable by a certain user.
> >Personally, I wouldn't use the web interface for downloading large amounts of
> >data anyway. On the command line, your imagination is the limit to what you
> >can do. [...]
>
> Dunno', I only ever use the web gui, as it's so easy, practical and
> straight-forward to use. Actually it's the main reason why I stick with BPC;
> IMHO a backup-system is as good as the gui is and how admin-friendly it is.
Yes, the interface needs to be admin-friendly. I define that as 'flexible'.
GUIs can't be as flexible as a command line. So, for me, a backup-system is
as good as the command line interface is.
Well, no. The primary job of a backup system is to do backups and allow
restores. If it's not reliable, then I don't really care about GUI or CLI.
Luckily, most of BackupPC's actions just happen automatically without admin
action. The GUI is great for checking the status. The rare event of a restore
is painless enough, and I don't have to 'jump through hoops' to prevent them
from being in-place.
> Personally I don't want to jump through hoops when I need to restore stuff
> quickly
My point exactly. I don't want to google what might be causing problems with
my 8 GB file (which is purely temporary), then run around and try all
computers until I find one where I can temporarily store the file, install a
new OS version somewhere if I don't find one, copy the file over the network
and from one disk to another several times ... why should I, when I can avoid
the large file (and the need to store it somewhere) altogether and be done
with the one single network transfer I can't get around anyway?
> - a few clicks in the gui and I'm done.
That does not seem to be what happened in this case ;-).
> As I said, it's my personal opinions and maybe not really on-topic. 8-)
That's fine, and that's what the GUI is there for in the first place. I had,
perhaps mistakenly, assumed that the command line version is quite
straightforward - it is, really, if you have set up and understood automatic
restores.
So let's get back to that topic, if you're still interested.
Regards,
Holger
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
