Hello, pon., 10 paź 2022 o 14:32 Marco Gaiarin <g...@linux.it> napisał(a):
> Mandi! Radosław Korzeniewski > In chel di` si favelave... > > > I'm not familiar with rsnapshot, but I'm curious how you manage rsnapshot > > archives on tape libraries which span multiple tape cartridges (other > media)? > > Ah, simply i put on tape the 'alpha.0' directory, the 'most recent backup' > in rsnapshot lingo. > It is marely a folder with all the file within. > So you are using a tar command for that, right? Then how do you restore data directly from tape? > > > The main purpose of virtual full is to create "current" Full backup > level based > > on data already available on backup media without connecting to the > backup > > client and making network traffic or any load on this client. > > Exactly what i need, indeed... > > > > It is not meant to minimize archive space. The space required to save > your > > backups will be the same regardless you execute virtual full or standard > full. > > No, probably i've explained not well... > > If the (file) pool have 3 media (files), ad the full is on the first media, > with some incremental scattered between other media/file, the virtual full > how 'pack' incremental in respect to media/files? > Virtual Full simply creates the next media and copies all required data from source media (your 3 current media in the pool). During copy Bacula skip all files marked as deleted in all Incremental or Differential backups. This procedure makes new (Virtual) Full backup indistinguishable from backup performed on the backup client. > > > >> Also, there's some way to 'offline init' a full backup in a > 'VirtualFull', > > A full backup in Bacula can be saved on any media on any location. It is > not > > required to make an "initial" upload. The incremental or differential > backups > > does not use this "initial" data saved on media, but it is using catalog > > metadata only. > > OK, so you are speaking of creating on the remote server, eg, a local > storage > daemon to make a full backup to a local volume (on a USB disk, supposing)? > Or, > eg, rsyncing the remote server to a local disk, connect tothe real storage > daemon and change temporarly the job definition to do an initial backup > from > local content and not remote one? > I do not understand your requirements. What is an "initial backup" you want to make? Are you referring to the first Full backup which has to be executed on the client? If yes and your network transfer speed is a main limiting factor in this case then the best solution is to make a small first "Full" and gradually add data to backup with incremental or differential levels. > The only solution that i see is to temporarrly move phisically the server > near the storage daemon and change temporarly the ip in the file daemon > definitition, do the initial full, and then return the server in place. > What is your limiting factor in this case? I cannot guess from your comments. best regards -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
