Fetch Older Ports Tree

Is it possible to fetch an older ports tree?
Before everyone starts saying I should always use the current most up to date ports tree, here's my scenario

A few months ago we built Server 1, updated its ports tree to what was current at the time.
Present Day, we are building a backup of Server 1 and would prefer that it be the exact same as Server 1, so that in the event of Server 1 dying we have a complete clone of it that can jump in and nobody would ever know the difference.

I have read the man page for portsnap, and the FreeBSD handbook covering ports does not mention this
 
You may be able to do this with csup(1) and extract the ports tree from a certain date.

Next time you create a server, you should build packages too.
 
Thanks, I don't know why I overlooked csup, looks like it should do what I need.

Do you happen to know where I can find the date/time of the ports tree snapshot I have installed, I see a unix timestamp in /var/db/portsnap/tag but I'm not sure if that is the date I'm looking for

I agree that creating packages at the time of installing everything would have been a good idea. Like I said the server was built months ago and no one had planed that we would build a future backup server for this one, but we learn as we go.
I would imagine making the packages and storing them in 2 or more secure places, HDD in a vault, and in NAS device so we can access the files from the network during the installation would be the way to go
 
geekspark said:
Do you happen to know where I can find the date/time of the ports tree snapshot I have installed, I see a unix timestamp in /var/db/portsnap/tag but I'm not sure if that is the date I'm looking for
I think the best 'guestimate' is done by looking at the date of /usr/ports/INDEX.
 
Do you mean use the mtime/ctime of the file itself as a reference? Because I did not see any timestamps or dates in the INDEX files when I searched the first time
 
geekspark said:
Is it possible to fetch an older ports tree?
Before everyone starts saying I should always use the current most up to date ports tree, here's my scenario

A few months ago we built Server 1, updated its ports tree to what was current at the time.
Present Day, we are building a backup of Server 1 and would prefer that it be the exact same as Server 1, so that in the event of Server 1 dying we have a complete clone of it that can jump in and nobody would ever know the difference.

Use rsync to copy the ports tree (/usr/ports) from the existing server to the new clone. That will also copy all the downloaded distfiles.

Better yet, back up the existing server with dump(8) and you get the ports tree and everything else, just as it is on the current server.
 
I've already thought of using rsync, and will be doing that and I already know how. We already use rsync to keep the user data synced, adding a rule for the /usr/ports was only logical already

I was asking about checking out older ports trees in the event that if I were not able to rsync or recover files from the server (or any other system that doesn't get backed up before disaster) I would still have my paper hardcopy of all the ports I've installed and I would be able to fetch the same ports tree in order to build the new system.

I can easily rsync right now, but I would like to test whether checking out an older ports tree would work if it did come down to that.

I just like to have backup plans for my backup plans and that's the original reason for this thread
 
[Solved]

Thanks a lot for your help, SirDice, I ended up using the most recent date/time I found in the /usr/ports/MOVED file as a reference
Inside of a test jail system I executed
Code:
echo '*default host=cvsup1.us.FreeBSD.org \
*default base=/var/db \
*default prefix=/usr \
*default release=cvs tag=. \
*default delete use-rel-suffix \
*default compress \
date=[cc]yy.mm.dd.hh.mm.ss \
ports-all' > /root/ports-supfile

csup -L 2 /root/ports-supfile
I compared the timestamps of files and the content of a few files that I know were updated in newer ports trees with the values of my old system and they all seem to match up the way I was hoping for
 
I meant the date of the INDEX file itself. But it's good to hear you managed using a different approach ;)

Wblock's idea is nice too :beer
 
Back
Top